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Preface 


...it  rthe  process  of  coinputer  proqramminq  ]  can  be  an 
aesthetic  experience  much  like  composinq  poetry  or  music. 

--Donald  Knuth 


All  art  is  quite  useless. 


--Oscar  Wilde 


Computer  proqram  engineer in q  is  a  discipline  directed  to  the 
production  of  computer  programs  that  are  correct,  efficient, 
flexible,  maintainable,  and  understandable;  in  reasonable  time 
spans,  at  acceptable  costs. 


J.J.  Horning 


This  bibliography  is  an  outgrowth  of  a  graduate  course  on 
computer  program  engineering  (C. 52105)  taught  in  1971  by  W.M. 
HcKeeman  and  in  1972-1974  by  J.J,  Horning.  As  part  of  the  course, 
students  were  asked  to  submit  an’^-otations  for  articles  that  they 
judged  to  be  anpropriate  for  inclusion  in  the  bibliography.  These 
submissions  were  then  edited  and  supplemented  by  this  editor  and 
his  predecessor,  J.D.  Gannon.  The  students  were  also  asked  to 
rate,  on  the  basis  of  relevance  and  quality,  a  number  of 
references.  These  ratings  appear  in  the  fcrm  n*ra,  where  n  is  the 
number  of  students  supplying  a  rating  and  ra  (<20)  is  the  mean  of 
those  ratings.  Tt  should  be  loted  that  the  ratings  reflect  the 
opinions  of  students  of  computer  program  engineering,  and  not 
necessarily  those  of  people  more  experienced  in  the  area.  Where 
possible.  Computing  E£views  review  numbers  are  also  cited  in  the 
heading  of  entries. 

The  bibliography  is  divided  into  eight  areas,  each  entry 
appearing  only  once.  A  finer  subdivision  appears  at  the  end  of 
most  sections,  giving  overlapping  lists  of  entries  relevant  to 
specialized  topics.  At  the  start  of  most  sections,  is  a  short 
list  of  those  references  that  the  editor  believes  to  be  of  special 
interest  —  either  because  they  represent  an  important 
contribution  to  the  area  or  oecause  they  contain  an  especially 
lucid  discussion  of  some  aspect  of  the  area.  Within  each  section 
the  <=^ntries  are  ordered  alphabetically  by  author  and  year.  There 
is  also  an  index,  arranged  by  author  and  year,  which  gives  the 
section  in  which  each  entry  is  contained. 

In  any  project  of  this  na*-ure  there  are  numerous  people  who 
deserve  to  be  acknowledged.  In  addition  to  the  students  in  2105, 
the  editor  would  like  to  thank  J. H.  Donahue,  J.J.  Horning,  and 
F.D.  Lazowska.  Special  thanks  are  due  to  Inge  Weber  who  wrestled 
valiantly  with  IiTS,  and  to  John  Gannon  whose  efforts  in  compiling 
the  first  two  editions  of  this  bibliography  made  this  third 
edition  possible. 
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Highly  Hecommended :  Brooks75,  Ruxton70,  Naur69b 


BAnEP72  CP25,047  3*18 

Bauer,  F.L.;  Software  Engineering;  Proceedings  of  IFIP  Congress 
71,  vol.  1  (1972)  pp. 530-538. 

A  definition  of  +-he  term  ’’software  engineering”  is  given  as  ’’the 
part  of  computer  science  which  is  too  difficult  for  the  computer 
scientist.”  The  aims  of  software  engineering  are  discussed,  along 
with  reasons  for  adopting  these  aims,  and  the  problems  involved  in 
meeting  them.  The  role  of  education  in  the  introduction  of 
software  engineering  techniques  to  the  programming  community  is 
mentioned,  and  the  resultant  obsolesence  of  present  programming 
techniques  is  predicted.  Problems  involved  in  applying  techniques 
of  industrial  engineering  to  software  are  explored,  and  solutions 
for  seme  are  offered.  The  role  of  structured  programming  as  a 
tool  for  application  of  those  techniques  is  investigated  at  some 
length,  and  some  problems  not  solved  by  this  tool  are  examined. 
The  concluding  remarks  present  some  ramifications  of  the 
techniques  and  philosophy  of  software  engineering  tor  the 
programming  community,  and  point  out  the  need  for  comparative 
testing  and  more  widespread  discussion  and  use  of  these  points  in 
order  to  achieve  progress  in  the  field. 


BAnF’573  CR26,  197  1*18 

Bauer,  F.L. ;  Software  and  Software  Engineering;  SIAM  Review, 
vol.15,  no. 2  part  2  (April  1973)  pp. 469-480. 

This  is  a  survey  paper  on  software  engineering.  It  is  discussed 
under  the  following  four  headings:  (1)  how  the  term  ’’software” 
developed;  (2)  how  software  was  (and  still  is)  developed;  (3)  how 
software  should  be  developed;  (4)  how  software  engineering  should 
develop  in  ’•he  future.  Under  (1)  and  (2)  a  brief  history  of 
software  and  its  relation  to  computing  is  given  all  the  way  back 
to  Babbage.  Tinder  (3)  the  software  crisis  is  analysed  and 
suggestions  for  its  mastery  are  given.  Finally  under  (4)  the 
problems  of  educating  the  ni^xt  generation  of  programmers  is 
discussed . 


3P00KS75  2*18 

Brooks,  F.P.  Jr.;  The  Mllhical  Man  Month,  Essays  on  Software 
Insineer inq;  Addison- Wesl ey  Publishing  Company,  (1975). 

This  is  an  informative  and  provocative  series  of  essays  on  the 
production  of  software,  written  by  the  original  manager  of  the 
OS/360  project.  Many  hard-won  insights  from  that  effort  are 
presented  and  related  to  other  work  in  the  area.  You  won't  agr^e 
with  everything,  but  you  will  find  food  for  thought. 


BP0WN7a 


1*13 


Brown,  P.J.;  Programming  and  Documenting  Software  Projects; 
Computing  Surveys,  vol.fS,  no.u,  (December  1  974),  pp,  2  1  3-220. 

Light-hearted,  easy  ro  read,  but  not  terribly  informative. 

RUX"f’ON70  1*18 

Buxton,  J.N.,  and  Pandall,  E.  (ed.);  Software  Engineering 
Techniques;  NATO  Scientific  Affairs  Division,  Brussels,  Belgium, 
(1970),  pp. 1-164. 

'^his  publication  is  organized  in  two  parts:  firstly  transcripts  of 
discussions  among  the  participants  of  the  conference  and  secondly 
a  collection  of  working  papers  presented  at  the  conference.  The 
emphasis  throughout  is  on  the  technical  aspects  of  real  problems 
rather  than  theoretical  or  management  techniques. 

Among  the  central  topics  of  discussion  are  software  quality  and 
flexibility,  the  problems  of  large  program  design  and 
implementation,  and  software  engineering  education.  Some 
interesting  highlights  are  the  discussion  of  the  Apollo  space 
program  from  the  computing  point  of  view  and  the  findings  of  IBM 
in  their  "super  programmer"  experiment. 

The  pap‘=‘rs  examine  specific  problem  areas  including  portability, 
software  reliability  and  software  evaluation. 

This  publication  presents  an  excellent  summary  and,  discussion  of 
the  problems  of  software  engineering. 


BUXT0N71  4*17 

Buxton,  J.N.;  The  Nature  and  Implications  of  Software  Engineering; 
in  Hugo,  J.S.  (ed)  ,  The  Infctech,  Ltd., 

Berkshire,  England  (1^71)  pp. 227-238. 

In  this  paper,  Buxton  attempts  to  make  clear  what  software 
engineering  is,  by  first  trying  to  define  computer  science,  and 
then  by  explaining  how  software  engineering  differs  from  it. 
Secondly,  he  discusses  the  essential  nature  of  software 
engineering. 


EOSDTCK72  4*11 

Fosdick,  L.D.;  The  Production  of  Better  Mathematical  Software; 
Communications  of  the  ACM,  vol.lS,  no. 7  (July  1972)  pp. 61 1-617. 

In  this  article  a  number  of  suggestions  are  made  for  future  work 
in  the  area  of  software  production.  Although  it  is  ostensibly 
oriented  towards  the  problem  of  the  production  of  mathematical 
software,  it  is  no-^  particularly  dependent  on  any  peculiarities  of 
this  class  of  software.  The  suggestions  are  divided  into  the 


-  3  ■ 


areas  of  design,  validation,  do«:u mentat ion  and  standards.  It 
points  out  the  strong  coupling  between  these  areas.  It  completely 
ignores  the  questions  of  the  organization  and  mechanics  of  the 
production  of  sof't-ware,  such  as  is  treated  in  Mills  and  Baker. 

The  article  is  uneven  and  perhaps  too  shallow  in  its  treatment  of 
the  problems  in  the  areas  discuss>Bd,  but  it  is  provocative.  It 
suggests  in  simple  terms  the  areas  that  every  programmer  must 
consider  if  he  is  to  be  able  to  bs  at  all  successful  in  producing 
worthwhile  programs.  It  provides  a  first  crack  at  a  reading  list 
for  programmers  in  support  of  their  professional  responsibilities. 
One  very  interesting  idea  emerges  from  the  article  and  that  is  the 
idea  of  truly  automatic  program  d acumenta ticn,  the  latter  to  be 
interpreted  in  a  broad  sense. 

MILLI:P74  1*12 

Hiller,  L.A.;  Programming  by  Non-Programmers;  International 
Journal  of  Han-Hachine  Studies,  vol.6,  no. 2,  (March  1974),  pp.237- 
260. 

This  article  is  a  study  on  the  result  of  one  attempt  to  extend  the 
understanding  of  the  behavioural  processes  and  problems  involved 
in  programming.  Twelve  non-programmers  solved  six  problems 
similar  in  nature  but  different  in  tests  (affirmation  vs. 
negation)  and  relations  (conjunction  vs.  disjunction). 

The  results  confirmed  earlier  results  that  negation  and 
disjunction  were  more  difficult  concepts  to  program  correctly. 
Certain  control  structures  were  identified  as  being  easier  to  use, 
and  it  was  no  +  ed  that  debugging  -^ook  an  inordinate  amount  of  time 
with  respect  to  the  initial  programming.  The  conclusions  bear  out 
what  some  people  already  feel  to  be  intuitively  obvious.  In 
particular,  the  structure  of  the  program  is  found  to  be  important 
to  its  efficiency  and  correctness. 


NAUP69b  14*18 

Naur,  P.,  and  Pandell,  B.  (ed.) ;  Software  Engineering;  NATO 
Scientific  Affairs  Division,  Brussels,  Belgium  (1969)  pp.  1-231. 


PIDDLE'7  2 

Riddle,  W.E. ;  An  Annotated  Eibljography  on  Software  Architecture; 
Stanford  Linear  A^ccelerator  Center,  Computation  Sroup,  no.  138 
(September  1972)  pp. 1-103. 


^nPSKl70  5*12 

Turski,  w.  (ed.);  The  Efficient  Production  of  Large  Programs; 
Polish  Academy  of  Sciences  (1970)  pp. 1-130. 
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Weinberg,  G,M.;  The  Ps^cholo^^ 
Nostrand  (1971)  pp.1-28B, 
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3,001  31*18 

of  Computer  Programming;;  Van 

discusses  the  art  and  science  of 
viewpoint  of  the  machines  and 
t-.hought  of  as  its  main  subject 
actors  viewpoint.  The  author 
mmer*s  psychological  makeup  which 
in  which  programs  vary  according 
nal  outlook  of  their  creators, 
looked  at  from  the  point  of  view 
The  effect  of  both  his  formal  and 
nd  without)  the  team  on  his 
a  is  considered, 

ants  in  the  fields  of  programming 
ograramers,  programming  aptitude 
many  others  based  on  empirical 
of  human  beings  and  their 

the  spirit  of  the  book  in  his 
sses  the  hope  that  the  knowledge 
e  programming  task  and  systems  in 
1  be  of  use  to  the  reader  in  his 
her  programming  environment. 


Highly  r0CO[nm‘=nHed :  Baker'72a,  M:'.lls7la 


ARON'^0  3*7 

Aron,  J.D.;  Estimating  Resources  for  Large  Programming  Systems;  in 
Bux-t-on,  J.N.,  and  Pandell,  B.  (ed.).  Software  Engineering 
Techniques  (1970)  pp. 68-79, 


AVOTS73  2*14 

Avots,  J, ;  taking  Project  Maragement  Work;  Datamation,  vol.19, 
no.1  (January  1973)  pp. 42-45. 

Discusses  the  human  and  technical  factors  (emphasizing  the  former) 
that  contribute  to  the  success  of  a  large  systems  project.  i^any 
management  tools  for  project  scheduling  and  reporting  are 
available  or  may  he  developed.  For  large  projects  they  will  be 
computer-based.  However  participation  in  planning  and  a  common 

understanding  of  procedures  and  goals  by  all  project  members  is 

essen-'-ial  in  order  to  sustain  the  necessary  enthusiasm  and  co¬ 
operation  . 

BAKEP72a  CP2 3, 1 1 3; 24,653  20*16 

Bak-r,  ^.T.  ;  Chief  Programmer  '"earn  Management  of  Production 
Programming;  IBM  Systems  Journal,  vol.ll,  no.1,  (1972),  pp. 56-73. 

This  pap<^r  combines  an  enunciation  of  the  principles  involved  in 

chief  orogrammer  team  org  an  iza‘*'.ic  n ,  and  the  problems  which  the 

approach  is  in-tended  to  solve,  with  a  description  of  how  the 
method  was  applied  to  a  particular  project:  an  information  bank 
system  for  the  Now  York  Timos.  The  general  specifications  for  the 
system  are  described,  and  an  outline  of  the  stages  of  de  volo  pm'^^n  t 
o'^  the  i  mploment  a'*'ion  is  given,  to  demonstrate  the  correlation  of 
th‘^  to-am  structure  with  rhp  way  it  which  the  problem  was  broker 
down  and  solved.  Statistics  are  given  to  indicate  how  the  various 
team  memb<=rs  spent  their  time.  Tie  paper  concludes  with  a  review 
the  benefits  ob-^ain*d  by  the  ohi^f  programmer  team  approach  to 
the  project. 

3AKEP72C  CP  25, 20  3  1*1  2 

Bakor,  F.T,;  Sys'^-^m  Quali-^y  ''hrough  Struc’-ured  Programming; 
Proceedings  of  the  FJCC,  vol.41,  (19'^2),  pp.  339-344  . 

An  interesting  addition  -^o  tlie  litera-^ure  concerniiig  chief 
programmer  teams,  this  ar'*‘icle  reiterat‘=^s  the  principles  b-hind 
th'^ir  organization.  None  of  this  ma*:erial  is  really  new,  but  the 
au'^hor  does  cite  some  previously  unpublished  statistics  obtained 
from  the  New  York  ilimes  information  bank  project.  Thp  figures 
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indicate  the  numbers  of  errors  of  various  types  which  occurred  in 
various  parts  of  thf^  project.  Paker’s  analysis  of  the  information 
supports  the  idea  that  rigorous  adherence  to  the  principles  of 
chief  programmer  teams  results  in  considerably  reduced  testing 
tim‘=-s  and  error  occurrences  after  product  delivery. 


BAKER73  1*16 

Baker,  F.T.,  i^ills,  H.  D.  ;  Chief  Programmer  Teams;  Datamation, 
vol.lP,  no. 12,  (December  1973),  i^p. 58-61. 

The  author  asserts  that  the  main  occupations  of  programmers  in  the 
^  radi-*- ional  management  structures  are  debugging  and  clerical 
chores.  The  chief  programmer  team  concept  is  presented  as  a  tool 
by  which  the  efforts  of  the  programmer  are  channeled  into  the 
tasks  of  design  and  programming  rather  than  debugging.  Integral 
to  this  concept  is  the  practice  of  structured  programming. 

The  author  gives  a  very  detailed  description  of  the  chief 
programmer  team  and  i-^-s  i  mple  meni:at  ion ,  drawing  on  considerable 
experience  to  illus-^rate  his  points. 


BAENETT70 


2*9 


Barnett,  A.,;  "^raining  Management  for  Effective  Data  System 
Development;  lEIP  World  Conference  on  Computer  Educat ion ( 1 970) . 


This  paper  concentrates  on  ■‘-.he  activity  that 
system  is  programmed.  The  premise  is  that 
trained  in  systems  development,  for  only 
systems  be  developed  to  perform  the  required 
realistic  and  satisfactory  constraints. 


takes  place  before  a 
management  must  be 
in  this  way  can  data 
functions  and  meet 


BFMER6D  11*12 

Berner,  P.W.;  Checklist  for  Planning  Software  System  Production;  in 
Naur,  P. ,  and  Randell,  B.  (ed.).  Software  Engineering  (  1969) 
pp. 165-180. 

The  implementation  and  production  of  software  systems  is  an 
expensive,  difficult  undertaking.  Good  planning  will  reduce  cost 
and  ti^e.  Here  the  author  provides  a  checklist  which  may  be  used 
for  planning  purposes.  The  checklist  includes  the  topics; 
tooling,  training  and  organization,  design,  scheduling  and 
costing,  production  control,  documentation,  quality  assurance, 
installation,  distribution  and  updating,  field  reporting  and 
maintenance. 


BEMEP.70  CR21,12  3  2*1  5 

Berner,  R.W.,  Manageable  Software  Engineering;  In  Tou,  J.T.  (ed.) 

vol.l,  (1870),  pp.  121-137. 
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This  is  a  very  readable,  well  written  paper  that  provides 
substantial  insight  into  •'■he  problems  of  managing  software 
production.  The  paper  states  seven  general  questions  that  should 
be  ashed  (and  completely  answered)  prior  to  the  production  of  any 
large  piece  of  software.  The  paper  addresses  these  questions  by 
asking  more  questions  and  giving  some  rather  alarming  statistics 
from  the  real  world. 

Included  in  these  statistics  are  some  figures  on  cost  per 
instruction  in  very  large  projects  and  also  real  life  experiences 
that  have  reduced  these  costs  dramatically.  One  point  made  in  the 
paper,  is  that  the  cost  of  system  modification  should  be 
considered  to  insure  that  changes  will  actually  be  cost  effective. 
An  example  related  to  this  point  is  that  of  an  actual  system 
modification  that  would  pay  off  only  if  the  software  were  to  be 
used  continuously  until  2040.  Th-^  real  life  examples  and  figures 
presented  in  this  paper  make  it  truly  worthwhile  reading. 


ROTRM73 

Roehm,  R.W.;  Software  and  its  Impact:  A  Quantitative  Assessment; 
Datamation,  vol,  19,  no.  5  (Kay  1973)  pp,48-S9. 


C0SgH0VF71  2*10 

Cosgrove,  J. ;  Needed  Now:  New  Planning  Framework;  Datamation,  vol. 
17,  no,  23  (December  1971)  pp, 37-39. 

The  author  describes  the  problems  of  programming  management.  He 
discusses  what  is  wrong  with  the  traditional  way  of  handling 
programmers,  and  how  they  should  be  dealt  with  in  this  time  of 
increasingly  more  complex  problems. 


FVANS70  1*15 

Fv?5ns,  D.J.;  '^he  Current  Sof-'-ware  Situation;  In  Evans,  D.J.  (ed.)  ; 
Soft  ware  Transcip-'-.a  Rooks,  London  (1970)  pp.  19-29. 

""his  gives  an  overview  of  the  various  major  software  areas  such  as 
assemblers,  compilers,  operating  systems,  and  software  packages, 
and  discusses  the  effects  of  the  rising  software  costs,  as 
compared  with  the  declining  costs  for  hardware. 


FTFNT73  1*14 

Fient,  H.G.;  Management  of  the  Acquisition  Process  for  Software 
Products;  Kanagement  Informatics,  vol. 2,  no. 3  (June  1973)  pp.153- 
164. 

A  discussion  of  software  brokerage  as  a  possible  solution  to  the 
increasing  cost  of  software  development  and  the  rising  tendency  to 
buy,  rather  than  develop,  application  software  with  the  consequent 
dissatisfaction  resulting  from  lack  of  standards  and  control.  The 


article  gives  -the  pros  and  cons  of  writing  one's  own  software  and 
an  overview  of  the  softwar*^'  product  market  giving  sources  of 
supply  and  information  and  lasting  typical  user  and  supplier 
complaints.  A  detailed  breakdown  of  the  requirements  typically 
encountered  is  given  coverinc  costs,  design,  ease  of  use, 
maintenance,  testing,  documentation  and  contracting.  Finally  a 
description  of  softwares  brokerage  detailing  services  provided  to 
user  and  supplier  is  given. 


GOTTEPER69 


CP ‘ 7,793 


Gotterer,  Management  of  Conputer  Programmers;  Proceedings  of 

the  SJCC,  vol.  34  (1969)  pp. 419-424. 


HALSTEAD''3  2*  ^  3 

Halstead,  M. H, ;  Language  Selection  for  Applications;  Proceedings 
of  the  SJCC,  vol,ii2  (June  1973)  pp.  21  1-21 4. 

The  author  outlines  guidelines  tor  selecting  a  new  language  for  a 
given  application.  Four  important  considerations  which  should  be 
recognized  when  making  such  d^^cisions  are:  1.  How  a  programmer 
spends  his  time  2.  Differences  ir  local  and  global  inefficiency  3. 
The  role  of  the  expansion  re.tio  4,  Variance  in  programmer 
productivity. 

While  describing  these  considera-t  ions,  the  author  points  out  costs 
which  va]:y  over  the  language  user  . 

Finally,  the  author  concludes  by  mentioning  those  critical  factors 
which  should  be  weighed  in  a  manc.gement  decision  for  an  alternate 
high  level  lanauage.  These  i.nvolve:  whether  the  higher  level 
language  (higher  than  what  is  cui-rently  in  use)  is  high  enough  for 
a  su f f icien ly  large  majority  of  program  applications,  that  data 
collected  on  small  programs  is  not  representative  of  the  crucial 
programs  (i.e.,  the  large  ones),  and  that  costs  of  conversion  from 
the  new  language  to  another  computer  are  a  very  important 
considera  t ion . 


HANEY72  CP: 5,504  3*12 

Haney,  M.  ;  Module  Connectioi  Analysis  -  A  Tool  for  Scheduling 
Software  Debugging  A.ctivities;  Proceedings  of  the  FJCC,  vol.  4  1 
(1972)  pp.  173-179. 

Presents  a  method  for  estimatiig  the  amount  of  work  necessary  to 
make  changes  to  a  larg^^  system,  c-r  to  complete  the  final  testing 
and  integration  of  such  a  system.  For  a  system  composed  of  M 
modules,  the  method  examines  an  n*n  matrix  of  estimated 
probabilities,  the  (i,j)th  elf ment  being  the  probability  that  a 
change  in  the  ith  module  will  recfuire  a  change  in  the  jth  module. 
Knowing  this  matrix  and  knowi.ng  the  number  of  initial  ("first 
order")  changes  (usually  correc.tions  of  bugs)  that  a  system 
requires,  one  can  then  easily  compute  how  rapidly  the  system 


converges  to  one  where  the  desired  changes  have  been  made  and  no 
undesired  changes  introduced,  and  whether  this  process  can  be 
expected  to  converge  at  all.  The  method  is  applied  in  evaluating 
a  strategy  for  releasing  new  versions  of  a  specific  example 
system . 

INTERNATIONAL  COMPUTFPS70  1*15 

International  Computers  Ltd.;  Programming  Procedures,  A 
Profesional  Approach  to  the  Planning  and  Control  of  Programming; 
International  Computers  Ltd.,  London,  England,  no. 4202  (1970) 
pp. 1- 250 . 

This  manual  includes  sections  on  project  organization,  project 
design,  program  design,  resource  planning,  programming,  and 
documentation.  Appendices  are  included  which  contain  examples  of 
real  working  documf=>nts,  and  actual  standards  for  common  languages 
(e.g.,  COBOL).  The  book  also  touches  on  personnel  allocation.  Of 
particular  interest  is  the  section  on  modular  programming, 
demonstrating  TCI’s  real-world  approach  to  a  theoretical  problem. 


JACKSON70  CR19,524  1*10 

Jackson,  B.J.;  Evaluating  Programmer  Workload;  Australian  Computer 
Journal,  vol.2,  no.1  (February  1970)  pp. 22-26. 

This  paper  discusses  the  problem  of  allocating  programmers  to 
programs,  so  as  to  ev‘=^nly  and  efficiently  spread  the  workload  and 
provide  an  estimate  of  how  long  it  will  take  to  write  a  given 
number  of  programs.  "n  order  for  a  supervisor  of  a  programming 
team  to  be  able  to  allocate  his  programmers  to  the  problem,  he 
must  know  the  number  of  programmers  in  the  team,  the  proportion  of 
time  each  sp<^nds  programming,  the  classification  of  all 
programmers  by  grade  of  experience  and  skill,  the  number  of 
programs  ♦ro  be  written  classed  by  complexity,  an  estimated  time  to 
write  these  and  ■♦■he  relationship  between  each  grade  of  programmer 
and  their  programming  output.  From  these,  the  author  develops  a 
Programmer  Rasa  Workload  Table  and  uses  it  to  develop  a  Programmer 
Workload  Allocation  Matrix,  from  which  job  allocations  are  made. 


KATZENELS0N71  CP22,551  1*6 

Katzenelson,  J. ;  Documentation  and  the  Management  of  a  Software 
Project  -  A  Case  Study;  Software  -  Practice  and  Experience;  vol.1, 
no. 2  (April-June,  1971)  pp. 147157. 

This  article  ’’describes  and  summarizes  experience  gained  by  a 
university  software  project  ...  writing  a  supervisor,  assembler, 
and  debugging  aids  for  a  small  4K  homemade  computer.”  Although 
useful  in  context,  (a  university  software  project),  it  may  be 
difficult  to  adapt  these  ideas  tc  a  large  application. 


KAY69 


CF  i7,794 


2*12 


Kay,  R.H,;  The  Management  and  Organization  of  Large  Software 
Development  Projectr:;  Proceec'ings  of  the  SJCC,  vol.34 
{  1969)  pp.  425-413. 

This  paper  discusses  common  management  problems,  presontir.g 
solutions  to  some  maior  problems  and  specifying  unresolved  areas. 
Some  important  key  words  are:  real  world,  human  aspects,  system 
specifications,  documentation,  pi  object  plan,  evaluation. 


LIEBOWITZ67  CF12,170 

Liebowitz,  P.H.;  The  Technical  Specification  -  Key  to  Management 
Control  of  Computer  Programming;  Proceedings  of  the  SJCC,  vol .  30 
(1967)  pp. 51-59. 


MASTEPS68  2*10 

Masters,  P.P.;  Evaluating  Programmer  Performance;  The  Australian 
Computer  Journal,  vol . 1 ,  no. 3  (Ncvember  1968)  pp.  124-  129. 

This  paper  discusses  the  fac'^  ors  that  influence  the  cost  of 
writina  programs  (it  is  suggested,  for  example,  that  programming 
time  is  linearly  proportional  to  program  size)  and  proposes 
several  means  of  measuring  the  p^^,  rf  or ma nee  of  programmers  in  order 
to  control  the  cost  and  effectiveness  of  the  programs  they 
produce.  These  measures  incli de  factors  such  as  program 
reliability,  how  long  took  tc  write  +-he  program  (both  calendar 
time  and  man  hours),  running  efficiency,  and  ease  of  modification. 
A  reporting  procedure  is  suggested  so  that,  at  all  times, 
management  knows  the  status  of  different  programs. 


MCMONir,ALL70  3*1  1 

HcMonigall,  J.P.;  Criteria  for  the  Design  and  Implementation  of 
Application  Packages  for  Third  Generation  Computers;  in  Evans, 
D.J.  (ed.)  ,  Software  70j_  Transcripta,  Ltd.,  London  (1970)  pd.92- 
97. 

HcMonigall  is  associated  with  a  software  house  that  provides 
application  packages  •*"o  its  own  service  bureau  as  well  as  to 
customers.  From  his  experience  in  applications  package  design,  he 
breaks  the  process  into  seven  phases:  pre-design,  market  research, 
initial  cost  estimation,  design  and  evalua-*-. ion  of  the  technical 
system,  post-design,  implementation,  and  systems  review.  The 
article  gives  an  overall  view  of  applications  package  design  and 
advocates  s-^-arting  from  scratch  design  as  opposed  to 
’’packageising"  an  existing  system. 


- 1 1- 


MICH3^KLSON6a  CPI 


Michaels 

on 

0 

s. 

;  How  t 

o 

Succee 

IFIP  Con 

gr 

ess 

1 

96  8,  vol. 

1 

(1968) 

This  is 

sho 

rt 

,  very  en 

j 

oyable  p 

it  was  w 

ri 

tte 

n 

in  the  da 

y 

s  when 

crit ical 

are 

a 

for  cone 

ern,  it 

However, 

H 

t  i 

s 

eminently 

suited  f 

the  so 

ft 

wa  r 

e 

problem 

really 

forsight 

in 

some  sugg 

e 

St  ions 

programm 

in 

g 

instead  of 

m 

anag ing) 

for  soft 

wa 

re 

success  is 

g 

iven. 

6,412  1*18 

d  in  Software;  Proceedings  of  the 
pp. 330-333. 

aper  on  software  prcblents.  Since 
software  was  just  becoming  a 
lacks  the  detail  of  later  papers, 
for  giving  a  concise  view  of  what 
is  and  demonstrates  remarkable 
(e.g.,  keep  good  programers 
Finally,  a  list  of  seven  items 


MILLS71a  14*16 

Mills,  H.D.;  Chief  Programmer  Teams:  Principles  and  Procedures; 
IBM  Federal  Systems  Division,  no.  FSC71-5108,  (June  1971),  pp.1- 
27. 


This  paper  describes  the  basic  functional  characteristics  of  the 
chief  programmer  team  method  of  project  management,  and  the 
principles  which  underlie  the  method.  The  objective  is  to  achieve 
a  practical  synthesis  of  several  contemporary  theories  of  good 
programming  practice.  The  concept  of  top-down  design  is  reflected 
in  the  hierarchical  structure  of  the  team.  Structured  control 
constructs  are  used  to  obtain  program  understandabi lity  and 
verifiability.  A  form  of  "egoless  programming,"  in  the  form  of  a 
"programming  production  library,"  is  introduced  "to  move 
programming  from  private  art  to  public  practice."  Dnfortunately , 
no  concrete  evidence  is  given  to  support  the  practicality  of  the 
approach . 


SCHWA.RTZ70 


6*14 


Schwartz,  J.D.;  Analyzing  Large-scale 
Buxton,  J.N.,  and  P.andall,  P.(ed.), 
Techniques  (April  1970)  pp. 122137. 


System  Development  ;  in 
Software  Engineering 


Very  larije  programs  are  defined  as  those  that  require  "many 
the  available  primary  storage"  for  code  and  data  and  require 
than  ten  coders"  for  implementation.  The  implementation  of 
systems  is  an  expensive,  difficult  undertaking  and  the  histor 
many  of  them  has  demonstrated  that  there  is  by  no  means  a  com 
under stand inq  of  the  methods  and  technology  necessary 
accomplish  successfully  the  aims  of  these  systems. 
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The  author  has  been  involved  in  the  design  and  chec 
number  of  large-scale  programming  systems.  He  first 
some  experiences  wi+h  large-scale  systems,  then  outlines 
the  problems  associated  with  large-scale  system  develop 
offers  some  recommendations  for  dealing  with  these  prob 
concludes  that  large-scale  system  development  is  a 
problem. 
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STM?10NS72 


2*13 


Simmor.s,  n.B,  ;  Art  of  writing  Large  Programs;  Computer,  vol.5, 
no. 2  (r’a  rch/April  1^72)  pp.43-4P. 

This  article  is  oriented  towards  alleviating  problems  one 
encounters  when  writing  large  programs  and  improving  programmer 
productivity.  First,  many  factors  such  as  poor  communications  and 
programmer  turnover  are  discussed  as  problem  areas  in  writing 
large  programs.  Then  techniques  for  improving  programmer 
productivity  are  discussed,  with  emphasis  on  improving 
commun ica -t-ion s  be'*-ween  programmers  and  managers,  users,  and  the 
general  environment.  The  areas  dealt  with  are  programmer  task 
assignment  and  supervision,  programmer  environment,  programming 
techniques,  and  program  documentation.  Although  a  brief  treatment 
of  all  these  topics  is  given,  the  author  seems  to  touch  on  most 
major  areas  of  concern  and  offers  practical  advice  as  to  how  to 
write  large  orograms. 


SMITH72b  CR23,741  1*16 

Smith,  D. ;  An  Organisation  foe  Successful  Project  Management; 
Proceedings  of  the  SJCC,  vol.40  ('lay  19^2)  pp.  129-140  . 

Describes  some  of  the  major  problems  in  software  development 
including  those  associated  with  u  isat isf act ory  products,  schedule 
delays  and  excessive  costs.  Gives  a  good  top-down  project 
management  design  which  presents  most  of  the  major  ideas  in 
general  projec-*-  management,  bu;  is  overly  general  depending  too 
much  on  intuitive  ideas. 


TPAPNFLL6 


CP  1  7, 822 


1*10 


Trapnell,  ^.M.;  A  Systematic  Approach  to  the  Development  of  System 
Programs;  Proceedings  of  the  SJCC,  vol.  34  (1969)  pp. 411-418. 


TSICHPIT7IS'^3 


4*10 


T  s  ich  r  it  x  J  s,  D.  ;  Project  Manag‘?ment;  in  Bauer,  F.L.  (ed.). 
Advanced  Course  in  Software  Engineering,  Springer- Verlag ,  New  York 
(1973)  pp. 374-384. 


WOLFE69  1*15 

Wolfe,  J.M.;  Testing  for  Programming  Aptitude;  Datamation,  vol. 15, 
no. 4  (April  1969)  pp. 67-72. 

WOLVFPTON74  1*12 

Wolverton,  R.W.;  The  cost  of  deveL. oping  Large-Scale  Software;  IEEE 
Transactions  on  Computers  vol.C-23,  no. 6,  (June  1  974),  pp.  615-636  . 
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WRIGHTea  CRl6,1ia  1*10 

Wright,  A. H,;  The  Management  of  Applications  Programming; 
Proceedings  of  TFIP  Congress  68  (Aug.  1968)  pp. 414-419. 

Discusses  applications  programming  only,  although  the  author  feels 
that  similar  problems  and  solutions  may  exis-^  in  other  areas  The 
paper  consists  of  36  numbered  topics  and  a  flowchart  showing  th<= 
training,  education,  and  career  patterns  for  programmers.  The 
importance  of  following  specifications  and  documentation  standards 
is  discussed  as  are  the  difficulties  involved  in  time-estimating 
and  progress  control.  Several  significant  ideas  appear  including 
the  importance  of  desk-checking  (by  two  people),  of  care  in 
preparing  code  and  test  runs,  and  of  complete  and  accurate  records 
of  all  development  decisions  and  test  runs.  The  team  organization 
for  supervision  of  programming  is  used. 


TOPICS 

Other  management  papers: 

Brooks75,  Corbato72,  Maynard72,  Mealy69,  Myers73,  Selig69, 
Steel65,  Tsichritzis72 ; 

Cost  estimation: 

Aron70,  Bemer69,  Eoehm73,  Evans70,  Halstead73,  Haney72, 
JAckson70,  Masters68,  f".aynard72,  McMonigall70 ,  Smith72b, 
Wolverton'^4 ; 
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Projt^ct  schedulinq: 


nem‘^r6P,  nrnoks75,  Garwick61,  Han«y72,  McMon iqa  1 170 ,  Mealy69 
Sniith72b; 

Personnel : 

?\rv‘^y73,  Darne^t70,  Peii'erfP,  nrooks7S,  Brown74,  Cosqrove71 
Griffith72,  Giind  erma  n7  3 ,  rn  t.  Computers70  ,  Judd70,  Kay69 
Masters^fl,  Maynard72,  M ichaelson63,  Schwartz70,  Wadsworth73 
Wol f e69 ; 

Orqanization  of  pGrsor.n‘^1  : 

Bak‘^rP2a,  Bemerbe^  Prophy70,  Cole73,  ConwaybB,  dackson70 
VillsBIa,  Mills73b,  Myers73,  Parnas72c,  Si[iiiiions72 ,  Sniith72b; 

Chief  programmer  teams; 

Baker72a,  naker72c,  Baker73,  Mills'^la. 


Ill*  I2£si3n 


Highly  recommpndpd  ;  narton70,  PfladyTI,  Dennis65,  Di  jksv  rafSR  b, 

Parnas72G 


ADPAMS70  CP20,82a 

Abrams,  P.S.;  An  API,  Machine;  Clearinghouse,  U.S,  Department  of 
Commerce,  Springfield,  Virginia  (February  1970)  pp.1-20U, 

ALEXANDFRaU  1*10 

Alexander,  C, ;  Notes  on  the  Synthesis  of  Form;  Harvard  University 
Press,  Cambridge  • 


PALZFR7la 


CP22,799 


3*12 


Balzer,  H.H.;  PORTS  -  A  Method  for  Dynamic  Interprogram 
Communication  and  Job  Control;  Proceedings  of  the  SJCC,  vol.3fl 
(1971)  pp.4PS-4nP. 


As  an  extension  of  Dataless  Programming,  one  should  be  allowed  to 
freely  interchange  physical  devices,  terminals,  files,  other 
programs,  and  a  monitor  as  the  object  of  a  specific  communication. 
By  using  PORTS  and  a  set  of  commands  such  as  CONNECT,  DISCONNECT, 
SEND,  RECEIVE,  CONDITIONAL  RECEIVE,  REQUEST,  and  CONDITIONAL 
REQUEST,  modules  may  be  reconnected  in  alternate  configurations  or 
"moni-^or  modules”  may  b'^  incorporated  between  the  input  and  ou-*-put 
of  two  or  more  componen*-.s  of  the  system.  Balzer  explains  his  ideas 
in  terms  of  his  Incremental  Systems  Programming  Language  which 
uses  an  extension  of  Dijhstra*s  semaphores. 


PALZEP71b 

Palzer,  F.M.;  On  tht^  Future  of  Computer  Program  Specification  and 
Organization;  Rand  Corporation,  Santa  Monica,  Cal.,  no.  R-622-ARPA 
(August  1^71)  pp.1-23. 


BAHTON70  CP.2  1,445  7*1  5 

Barron,  R.S.;  Ideas  for  Computer  :;ystems  Organization:  A  Personal 
Survey;  in  Tou,  J.T.(ed),  Softwar^^  pp.7-16. 

Barton  presents  arguments  in  support  of  his  preferences  for  a 
large  variety  of  systpms  featurej;.  In  the  paper  he  supports 
vary  ing- lengt  h  over  f  ixed-lengt  paging,  variable-length  slices 
for  partitioning  processor  time,  Polish  notation  for  expressing 
statements  and  procedures,  structured  programming  without  GOTO's, 
the  elimination  of  directly  controlled  indexing  (i.e.,  APL  type 
operations  are  pref<=»rable)  ,  aid  varying  length  (programmer- 
defined)  storage  mappings. 
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BELADYTI  1*14 

Bel^dy,  L.A. ,  and  Lehman,  M.M,;  Programming  System  Dynamics  or  the 
Meta-Dynamics  of  Systems  in  Maintenance  and  Growth;  IBM  Research 
Center,  Yorktown  Heights,  no.  PC3456,  (September  1971). 

A  model  is  developed  for  large  programming  systems  in  which 
continuous  repairs  and  enhancements  occur.  This  primary  effort 
leads  to  fragmentation  of  the  system  and  of  the  repairs  and 
enhancements,  and  is  shown  to  be  linearly  bounded  by  cost. 
However,  a  secondary  and  exponential  effort  shows  up  because  of 
correlation  between  fragments,  communications  among  others  working 
in  parallel,  and  maintenance  of  documentation.  There  is 
initially,  in  practice,  a  decay  in  the  secondary  effort  due  to  the 
initial  accuracy  and  correctness  of  the  system;  however,  the 
authors  believe  this  is  only  temporary  in  nature,  i.e.,  the  effort 
to  maintain  the  resultant  work  is  itself  always  exponential  due  to 
the  same  factors. 

By  identifying  these  linkages  of  communic 
critical  points  the  authors  feel  that 
development  methodology,'*  which  includes 
variables  and  adopting  unspecified  but 
documentation,  is  essential.  Since  the 
term  never  vanishes,  their  objective  is 
cost  growth  of  maintaining  large  systems, 
reguireraent  is  "to  guantify  complexity  of 
plan  precisely  for  the  development, 
ultimate  termination  of  a  system,  and  its 


ERINCH  HANSEN70  CP19,620  3*10 

Brinch  Hansen,  P.;  '^he  Nucleus  of  a  Multiprogramming  System; 
Communications  of  the  ACM,  vol.13,  no. 4  (April  1970)  pp.238- 

2h1,250. 


EROWN'^I  CP2  3,004  2*10 

Brown,  F.D,,  Calderbank,  V.J.,  and  Poole,  M.D.;  Some  Comments  on 
the  Portability  of  a  Large  ALGOL  Program  -  The  Implementation  of 
SID  on  KDP9;  Software  -  Practice  and  Experience,  vol.1,  no. 4 
(Oct. -Dec.  1971)  pp. 367-371. 

In  this  paper  the  authors  desc ibed  their  task  of  moving  a  large 
program,  SID,  written  in  ALGOL,  to  a  new  machine,  KDF9.  For  doing 
this,  four  major  difficulties  were  considered:  (1)  Is  the  task 
performed  by  the  program  independent  of  the  environment?  (2)  Is 
the  language  of  the  program  a  subset  of  the  dialects  accepted  by 
both  ALGOL  compilers,  and  do  these  compilers  interpret  this  subset 
identically?  (3)  Does  the  pregram  satisfy  all  the  quantitative 
constraints  imposed  by  the  target  compiler?  (h)  Is  a  conversion  of 
hardware  representation  neces£;ary,  if  so,  is  it  a  trivial 
operation? 
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BUSHNELL71  1*15 

Pushnell,  P.C.;  Usf^r  Modifiable  Software;  Ha t heroat ical  Software, 
Academic  Press,  New  York  (1971)  po, 5^-66. 

This  paper  presents  arguments  for  easy-to-modif y  software  in  a 
short,  well- written  paper.  Although  written  with  regard  to 
mathematical  systems,  the  suggestions  given  on  how  to  write 
modifiable  software  can  have  wider  applicability. 


COHEN72  2*14 

Cohen,  A.;  Modular  Programs:  defining  the  Module;  Datamation, 
vol.lB,  no.1  (Jan.  1972)  pp. 34-37. 

Modular  programming  is  a  useful  tool  if  applied  skillfully.  The 
author  gives  a  feeling  for  the  right  decomposition  of  your  problem 
into  modules  by  considering  typical  file  processina  programs. 


CONSTANTIWE66  CPI  3,619 

Constantine,  L.L.  (ed.)  ;  Concepts  in  £1221^2.  £2sign  ;  Paragon 
Press,  Somerville,  Mass.  (1966)  pp.  1-154. 


CONWAY6a 

Conway,  M , E. ;  How  Do  Committees  Invent?;  Datamation,  vol.  14,  no. 
4  (April  1969)  pp. 29-32. 

Organizations  which  design  systems  are  constrained  to  produce 
designs  wnich  are  copies  of  the  communication  structures  of  these 
organizations.  The  author  presents  a  criterion  for  the 
structuring  of  design  organizations  according  to  the  need  for 
ccmmiinication . 


C0RBAT072  CR25,199  5*9 

Corbato,  E.J.,  Saltzer,  J.H.,  and  Clingen,  C.T.;  MULTICS  -  The 
Eirst  Seven  Years;  Proceedings  of  the  SJCC,  vol.  40  (1972) 
op. 57 1-583. 

Although  intended  as  a  review  and  current  status  report,  this 
paper  provides  an  interesting  description  of  the  progress  of  the 
design  and  implementation  of  a  very  large,  very  complex,  research 
project  with  real  life  goals.  In  their  conclusions,  the  authors 
make  the  point  that  computer  utility  systems  must  evolve,  since 
thc>  costs  of  redesign  and  re-implementation  are  too  high  to  allow 
any  o-^her  procedure.  This  is  almost  certainly  true  of  any  very 
large,  complex  system  which  is  tc  serve  a  community  of  users  who 
(1)  will  not  wait  for  the  ultimate  to  arrive  at  the  expense  of  not 
doing  anything  until  it  does;  (2)  are  used  to  a  particular 
environment,  and  see  no  real  need  to  unlearn  everything. 


C0X71 


2*15 


Cox,  P.R.;  Machine  -  Tndependei.t  Operating  Systems:  A  Functional 
Approach  To  Df'sign;  in  Hugo,  J.:;.(ed,)/  The  Zourth  Generation, 
Infotech,  Ltd.  (1^71)  pp.23P-2S8, 

The  ••■erro  operating  system,  as  currently  used  ir.  the  computer 
industry,  is  vir-’-ually  undefinable.  There  is  a  large  set  of 
functions  that  nearly  all  opercting  systems  do  perform,  but  this 
set  is  inclined  to  become  a  little  fuz2y  around  the  edges. 

In  this  paper,  Cox  attempts  to  set  forth  objectives  that  are 
reguired  in  a  machine  -  independf nt  operating  system  and  portable 
software  at  the  higher  level.  He  feels  that  more  thought  is 
required  as  to  the  function  of  operating  systems  and  the 
philosophy  behind  ■^hera,  rather  than  on  what  a  particular  machine 
or  a  particular  operating  system  does. 


DAKIN73 


2*1  1 


Dakin,  F.J.,  and  Poole,  P.C. ; 
Journal,  vol.16,  no. 3,  (August 


A  Mixed  Mode  Approach; 
1D73)  pp. 219-222. 


The  Comput«^r 


This  paper  uses  the  development  of  a  version  of  the  MITEM  text 
editor  to  describe  the  notion  of  mixed  coding.  This  consists  of 
using  interpretive  and  direct  code  in  the  same  system.  Also 
discussed  are  the  adaptability  of  code  generation,  selective 
optimization  of  run  time  and  procram  space  in  code  generation. 


The  syst'^m  was  firs-^  run  interpre tive ly  and  monitored,  to 
that  ninty-seven  percent  of  the  execution  time  was  spent 
than  ten  per  cent  of  the  source  code.  These  frequently 
portions  were  changed  to  direct  c-ode,  and  the  rest  of  the 


.  This  mixture  combines  the  speed  of 
space  utilization  of  interpretive 


left  interpretive 
and  the  f-fficient 
run-time  overhead  of  mixed  code  was  found  to  be  very 
ran  three  to  five  times  faster  than  the  interpretive 
being  only  10-20*^  slower  than  th€‘  direct. 
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Another  benefit,  which  is  discussed,  is  the  adaptability  of  the 
sof-^ware,  which  it  creates.  Also  having  some  interpretive  code, 
gives  powerful  debugging  an<.  easy  monitoring  capabilities. 
Finally  the  au‘*'hor  gives  some  id€  as  on  how  a  mixed  code  software 
development  sys-^.em  might  operate. 


DENIL73  1*10 

Denil ,  N.J.;  Software  Design  with  Invocation  Diagrams;  SIGPLAN 

Notices,  vol.8,  no.D  (September  ‘973)  pp.57-FD, 

The  author  describes  a  mediun.  for  expressing  abstractions  of 
programs  (especially  their  struct. ure).  He  claims  programs  can  be 
designed  top  down  with  this  medium;  only  the  ’’logic  of  the  design” 
is  crucial.  The  medium  provides  for  diagrams  of  data  and 
structure  of  the  programs  as  observed  from  the  program  modules. 
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the  data  communioated  between  modules,  and  the  effects  each  module 
has  on  the  communicated  data. 


r)ENNlS65  CFIO^CSS  .1*12 

Dennis,  J.B.;  Segmentation  and  the  Design  of  M u 1 ti progr amme d 
Computer  Systems;  Journal  of  the  ACii,  vol.12,  no.  4  (October  196S) 
pp, 5RD-602. 

A  mu Iti prog  rammed  computer  system  must  be  designed  so  that  the 
available  computational  resources  are  applied  to  the  computations 
in  progress  in  a  manner  sue!’  that  these  resources  are  most 
effectively  utilised.  To  maintain  a  balance  between  demand  and 
supply  and  to  ensure  a  fast  response  of  the  system  to  changing 
externa]  conditions,  it  is  essential  that  the  system  design 
includes  features  that  allow  physical  resources  to  be  rapidly 
reallocated  among  the  computatioi s  being  mult iprogr amme d ,  This 
paper  studies  the  problem  of  naking  effective  reference  to  data 
and  procedure  information  which  vill  reside  in  different  physical 
memory  locations  during  the  course  of  a  computation  as  a  result  of 
relocation  activity. 


DEPEf1ER74  1*15 

DaRemer,  F.L.,  and  Kron,  H, ;  Prog  ram ming- in- the- sraal 1  versus 
Programm ing- in-the-large;  to  app<,!ar  in  75  International  Conference 
on  Reliable  Software. 

The  authors  of  this  paper  distinguish  two  types  of  programs: 
’•small”  programs  of  less  than  a  few  pages  in  length  and  easily 
comprehended  by  a  single  programmer,  and  ’’large"  programs,  which 
include  all  others  hut  usually  mean  systems  containing  other 
modules,  perhaps  written  by  sG\eral  different  programmers.  They 
argue  tha-’-  today’s  languages  are  adequate  only  for  progra  mming-in- 
the-small,  and  that  a  new  language  is  needed  to  specify  how 
smaller  modules  are  linked  together  to  form  a  system. 

A  prototypf^  language  called  MIL/1  is  described.  Advantages 
include  a  compiler  checkable  specification  of  a  greater  amount  of 
th«=  intent  of  the  programmer;  tools  for  project  management  and 
documentation;  and  a  means  of  communication  between  members  of  a 
programming  team,  especially  a  c]  ief  programming  team. 


DIJKSTRA58b  C’'14,979  19*13 

Dijkstra,  S.W.;  The  Structure  of  the  "THE"  Multiprogramminq 
System;  Comraunica-’-ion  s  of  the  ACI',  vol.11,  no. 5  (May  1968)  pp.341- 

346. 

The  design  of  the  T, H. E  Multiprogramming  system  is  discussed  with 
an  emphasis  on  methodology.  The  basic  unit  in  this  system  is  a 
process  and  these  are  organized  on  hierarchical  levels  which  serve 
o  implement  independent  abst  rad,  ions .  Program  correctness  and 
verification  are  briefly  discussed  and  a  short  appendix  gives  some 
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explanation  of  semaphores  and  some  results  on  prevention  of 
deadlock , 


DIJKSTRA69  9*14 

Dijkstra,  F.W.;  Complexity  Controlled  by  Hierarchical  Ordering  of 
Function  and  Variability;  in  Naur,  P.,  and  Randell,  B,  (ed.)# 
Software  Fngineering  (196  9)  pp. 1^^1-185, 

The  principle  of  operating  system  design  as  an  ordered  sequence  of 
machines,  each  succeeding  one  more  attractive  (to  the  user)  is 
presented.  Each  machine  is  implemented  by  an  additional  layer  of 
software  over  the  basic  machine,  A  description  and  i ustif ication 
for  the  particular  layers  used  in  the  T,H,F,  System  is  also 
given . 


GAHTHIERVO  CR20,B29 

Gauthier,  R,L,,  and  Ponto,  S,  D,  ;  HesiniiiM  Systems  Programs ; 
Prentice-Hall,  Inc,  (1970)  pp,  1-274, 

A  textbook,  complete  w i+ h  problem  sactions,  designed  to  give  an 
overall  view  of  the  problem  of  implementing  a  large  software 
project,  and  to  provide  a  reference  collection  of  programming 
techniques.  The  development  of  these  ideas  is  based  on  the  modular 
design  and  logical  structure  of  a  compiler  system. 


GHAN71  CR22,433 

Ghan,  L. ;  Better  Techniques  for  Developing  Large  Scale  FORTRAN 
Programs;  Proceedings  of  the  26th  ACM  National  Conference  (1971) 
pp.  520-S3'7. 

Cost  reductions,  particularly  in  the  development  of  large  scale 
FORTRAN  scientific  computer  programs,  are  desirable,  but  are  not 
easy  to  realize  because  of  enduring  development  problems 
associated  with  large  programs.  This  paper  examines  the  more 
significant  of  these  problems  and  suggests  ways  to  treat  them.  The 
problems  addressed  here  were  identified  over  a  period  of  years 
spent  developing  a  family  of  large  FORTRAN  simulaticn  programs  at 
Boeing.  The  techniques  discussed  were  evolved  during  the 
development  of  these  programs  and  are  of  proven  effectiveness. 
Particular  <^mphasis  is  placed  on  the  use  of  higher  level  software, 
interproqram  communication  techniques  and  good  basic  coding 
pract ices . 


GILL69 


Gill,  S.;  Thouah-^s  on  the  Sequence  of  Writing  Software;  in  Naur, 
P,,  and  Pandell,  P,  (ed.).  Software  Engineering  (1969)  pp,186- 
188. 
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GUNDEPMAN73 

Gunderman,  P.E.;  A  Glimpse  into 
vol.19,  no, 6  (June  1973)  pp.99-1C 

Program  main-t-enance  is  descrih 
growing  area  of  activity  which  is 
manpower,  computer  use,  prof 
attributed  to  maintenance  having 
as  an  activity  for  second  cl 
capable  of  original  program  devel 
literature  and  research  on  de 
system  problem  and  the  implicatic 
the  organization  of  an  effec 
d iscussed , 


GnTTAG75 

Guttag,  J.V. ;  Dyadic  Specificati 
in  Three  Approaches  to  Reliable  S 
Specification,  and  Complementai 
Compu-^-er  System  Research  Group,  D 
1975)  . 

The  specification  of  data  types 
a  procedural  or  a  descriptive  ma 
advantages  and  its  limitations 
specification  technique  combini 
procedural  and  descriptive 
impl ica*- ions  for  structured  desic 
proofs,  and  program  testing.  Hi 
specification  system  that  will  re 
set  of  axioms  sufficient  to 
i m pie men t at ion-ir  depen den  t  manner 


HABER  MAN N7 3 

Habermann,  A.N.;  Integrated  Des 
(September  1°73)  pp.6u-66. 

An  argument  is  given  for  the  ini 
and  implementation  efforts  of 
production  effort  in  which  docum^^ 
it  is  argued  that  the  design  cone 
the  language  chosen  for  imple 
project. 


5*13 

Program  Maintenance;  Datamation, 

1. 

ed  as  ”a  large  and  continually 
taking  its  toll  in  time,  money, 
its,  etc.”  These  problems  are 
been  largely  ignored,  or  viewed 
ass  programmers  who  are  not  yet 
opment.  The  lack  of  published 
bugging  is  a  problem,  A  typical 
ns  of  fixing  it  are  described  and 
tive  "maintenance  facility”  is 


1*18 

on  and  its  Impact  on  Reliability; 
oftware:  Language  Design,  Dyadic 
y  Semantics;  Technical  Report  44, 
niversity  of  Toronto,  (January 


is  normally  carried  out  in  either 
nner.  Each  technique  has  its 
.  Guttag  presents  an  algebraic 
ng  the  best  features  of  the 
approaches.  He  discusses  its 
n  and  specification,  correctness 
s  eventual  goal  is  an  interactive 
cognize  (and  help  construct)  a 
fully  describe  a  data  type  in  an 


3*10 

ign;  SIGPLAN  Notices,  vol.8,  no. 9 

egration  of  the  design,  analysis, 
a  programming  system  into  one 
ntation  is  a  primary  issue.  Also 
epts  should  not  be  presented  in 
mentation  as  it  may  dominate  the 


HALS':’EAD7  2  6*5 

Halstead,  M.H.;  Natural  Laws  Controlling  Algorithm  Structure?; 
SIGPLAvN  Notices,  vol.'^,  no. 2  (February  1972)  pp. 22-30  , 

The  author  proposes  that  algorithms  obey  natural  laws,  which  are 
based  on  two  independent  propfirties,  the  number  of  distinct 
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operators  and  the  number  of  distinct  operands.  A  certain  function 
of  these  properties,  called  the  Internal  Quality  of  an  algorithm, 
is  said  to  be  independent  of  the  language  in  which  the  given 
algorithm  is  expressed.  The  statistics  pres'^nted  are,  tc  say  the 
least,  unconvincing. 


HOPKINS70  1+12 

Hopkins,  M.F.;  Computer  Aided  Software  Design;  in  Buxton,  J.N., 
and  Randall,  E,  (ed.).  Software  Engineering  Techniques  (1970) 
pp. 99-101, 


H0PNING74<i  2*16 

Horning  J.J.;  What  the  Compiler  should  tell  the  User;  Advanced 
Course  on  Compiler  Construction,  CH-5-D,  (March  1974),  pp,1-23. 

An  excellent  article  which  should  be  read  by  anyone  who  is 
starting  to  write  a  compiler,  Tt  describes  the  needs  of  the 
programmer  who  will  be  using  the  compiler,  emphasizing  the  fact 
that  all  programs  have  errors  in  them  when  they  are  first  written. 
The  fast  development  of  correct  programs  requires  an  intelligent 
solution  to  the  problems  of  error  detection,  diagnosis,  and 
documentation  by  the  compiler  so  that  the  user  may  easily  discover 
his  mistakes.  Output  should  be  in  language  understandable  by  the 
user  (who  should  not  be  expected  to  knew  compiler  jargon)  .  Tn 
fac^,  for  anyone  writing  a  program  to  be  used  by  soraeDne  else, 
this  article  could  be  used  as  a  guide  to  what  should  appear  in  the 
program  output.  Perhaps  a  better  title  would  be  "What  the  Program 
Should  "'ell  the  User," 


JUDD7e  CP19,435  5*9 

Judd,  P.;  Prac+-ical  Modular  Programming;  Computer  Bulletin, 
vol.lh,  no, 1  (1970)  pp,4-7. 

The  obvious  merit  of  modular  programming  is  that  it  enables 
programming  to  be  divided  among  several  programmers;  working 
concurren-t- ly ,  and  allows  better  testing  and  validation  by  groups 
who  may  not  be  aware  of  the  detailed  methods  used  in  a  particular 
module. 

The  author  of  this  paper  is  particularly  interested  in  large- 
system  implementation  and  his  treatment  of  modular  programming 
contains  valuable  suggestions.  At  times  his  viewpoints  differ  from 
the  current  standards  and  he  touches  on  some  controversial  issues 
such  as:  are  supervisors  really  capable  of  reading  the  code  of 
their  subordinates,  should  a  company  employ  junior  programmers  to 
save  expenses,  should  the  master  plan  of  a  project  be  known  only 
by  the  team  leader  and  should  the  junior  staff  be  involved  in  the 
creative  aspects  of  the  project. 

In  the  author’s  opinion  no  definition  of  module  is  meaningful  if 
it  disregards  the  application  program  of  which  it  forms  a  part. 
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Certain  problems  define  their 
case  of  file  handling  programs  th 
record  type,  for  each  transac 
processing  etc.  The  modules  shou 
maintenance  purposes  but  the 
naturalness  to  the  problem.  Any  r 
should  be  at  the  interface  1 
functioning  level.  The  paper  sug 
should  be  handled  by  one  module  a 
reguired,  these  should  be  execute 
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LISK0VT2  CH25,795 

Liskov,  B.H.;  A  Design  Methodology  for  Reliable  Software 
Proceedings  of  the  FJCC,  vol.41  (1972)  pp.  191-199. 

This  paper  presents  a  methodology  for  the  development  of 
software.  It  begins  by  justifying  the  development  of 
methodology  in  light  of  the  failure  of  existing  methods  ( 
extensive  debugging)  to  produce  reliable  software.  Th 
then  describes  a  two-part  methodology  derived  from 
experience  wi+h  a  large  software  project. 

The  first  part  involves  the  lefinition  of  a  "good 
modularization,  in  which  the  system  is  organized  into  a 
of  ’’partitions”  each  corresponding  to  a  level  of  abstrac 
having  minimal  connections  with  one  another.  The  tota 
design  is  then  expressed  as  a  structured  program,  rand 
design  amenable  to  existing  proof  technigues. 


The  second  part 
design  with  good  m 
author  as  the  id 
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The  paper  ends  by  describing  experiments  in  the  u 
methodology  in  progress  at  the  time  of  presentation. 
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,  J.W.;  A  Modular  Approach  to  File  System 
e  SJCC,  vol.34  (1969)  pp.1-13. 

odel  for  the  design  of  sophisticated  file 
s  of  hierarchical  modularity  and  virtual 
g  the  model,  an  example  of  an  environment 
omputer  network  with  the  problems  of 
file  directories,  and  removable  volumes 
les  described  are  the  I/O  control  system, 
file  organization  strategy  modules,  basic 
system,  and  access  methods  and  user 
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interface.  The  goals  and  requirements  of  each  of  these  modules 
are  discussed. 


MADNICK70  1*8 

i^adnick,  S.E,;  Design  Strategies  for  File  Systems;  Project 

MAC,  no.TE-78  (October  1^70)  pp, 1-106. 

This  report  exemplifies  the  i ^ea  of  "top-down”  or  "levels  of 
abstraction"  analysis  as  applied  to  the  design  of  file  systems. 
The  two  basic  concepts  impose!  on  the  analysis  are  that  files 
should  (except  for  the  top-most  user-oriented  level)  be  subject  to 
a  uniform  representation,  and  that  the  tasks  of  naming,  storing 
and  retrieving  information  should  be  analyzed  into  a  hierarchy  of 
activities  ranging  from  the  pureljT  logical  to  the  purely  physical. 

A  file  is  viewed  as  a  named,  sequentially  organized  (virtual) 
memory.  That  is,  the  items  of  information  in  the  file  are 
considered  to  be  assigned  to  sequential  "addresses."  The  fact  that 
the  items  are  (say)  related  by  a  tree  structure  is  of  no  interest 
except  in  the  top-most  user-oriented  level  of  the  system. 


MCILHOY6D  2*10 

Mcllroy,  M.D,;  Mass  Produced  Software  Components;  in  Naur,  P.  ,  and 
Randell,  B.  (ed . ) ,  Software  Engineering  (1969)  pp. 138-155, 


MEALY6P  CF 1^,621  3*14 

Mealy,  G.H.;  The  System  Design  Cycle;  Proceedings  ACM  Second 
Symposium  on  Operating  Systems  Principles  (Oct.  1969)  pp,1-7. 

The  steps  in  a  design  of  a  project  are  discussed  along  with 
popular  design  pitfalls.  The  steps  are  divided  as  follows:  1, 

Gross  design  (or  architecture)  2.  Design  plan  for  next  stages  of 
project  3,  Detailed  design  of  project  4.  Development  plan 
(implementation) .  Also  the  author  feels  that  programmers 
underrate  the  importance  of  market  considerations  in  system  design 
and  that  technical  competence  should  include  an  appreciation  of 
these  problems.  Among  the  problems  discussed  are  headlong  rushes 
to  implement  without  a  complete  and  evaluable  design,  inadequate 
market  information,  and  ignorance  of  Conway's  Law  which  states 
that  systems  resemble  the  organizations  which  produced  them. 


M0PRIS71 

Morris,  n,;  The  Nature  and  Benefits  of  Modular  Operating  Systems; 
in  Hugo,  J.S.  (ed)  ,  The  fourth  Generat^ion,  Infotech,  Ltd,, 
Berkshire,  England  (1971)  pp, 279-298, 


M0SEDALE73 


-2'“ 


1*1  1 


Mosedale,  T.W.;  PEDANT:  A  Ccmputerized  Support  to  Program 
Modularity  Under  Limited  Memory  Conditions;  Software  -  Practice 
and  Experience,  vol.3,  no.  2  (Apiil-June  1973)  pp.121-1<i3. 


The  author  notes  that 
used  in  hardware,  and  su 
points  out  that  modu 
driver/buffer  program, 
interface.  PEDANT  is 
simplify  applications  whe 
considered  to  be  undefin 
module  blocks.  PEDA.NT,  a 
requests  for  data,  and 
PEDANT  is  basically  a  lin 
ignore  the  source  of 
treat  data  as  a  resource. 


the  "building  block  approach"  is  already 
ggests  its  extension  to  software.  He 
larity  does  not  always  eliminate  the 
but  requires  a  skillfully  created 
designed  to  work  with  large  modules,  to 
re  memory  size  is  small.  Data  areas  are 
ed  until  referenced,  and  thus  outside  the 
cting  a£:  an  interpreter,  handles  all 
for  communication  with  other  modules, 
k  and  load  software  system.  Modules  can 
data  (i.e.,  in-core,  disk,  tape)  and  can 
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Myers , 
vol. 19, 


1*20 


G .  *J . 
no.  9 


Characteristics  or  Composite 
{Sept.  1973)  pp. 100-102. 


Design;  Datamation, 


An  essentially  unsatisfying  discussion  of 
highly  modular  programs.  Suggests  that  the 
composed  of  "strong"  (closely-coupled  internally) 
with  a  well-defined  function  and  predictable  results, 
few  arguments  as  possible.  No  real  life  example  of  such  design,  or 
its  supposed  advantages  (quickly  vritten,  easily  debugged,  easily 
changed)  is  provided. 


design  criteria  for 
goal  is  a  program 
modules,  each 
linked  by  as 


Program  ;;tructure  follows  sociil  structure  (Turski70)  .  The  two 
key  statc?ments  in  the  paper  are:  "Because  of  the  high 

independence  wi-^hin  the  program,  interactions  and  dependencies 


among  programmers  are  reduced." 
easily  shifted  to  smooth  out 
requirements . " 


"Programmer  assignments  can  be 
the  peaks  and  valleys  on  resource 


NEEDHAM70a 


Needham,  P.M. 
System  Design  and 


Software  Enginearing  Techniques  and  Operating 
Production;  in  Euxton,  J.N.,  and  Randell,  B. 


(ed) ,  Software  Engineering  Techniques  (1970)  pp. 111-113. 


NEELY73 


CR27, 210 


1*12 


Neely,  P , M. ;  On  Program  Control  Structure;  Proceedings  of  the  ACM 
Conference,  (1973),  pp. 119-125. 


This  paper  is 
syntactic  format 
forms,  first  a 
the  code  easier. 


primarily  concerned  with  the  improvement  of  the 
of  DO-WHIIE  loops.  The  improvements  take  two 
standard  set  of  indentation  rules  to  make  reading 
and  second  the  semantics  of  the  logical  control 
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of  iteration  are  separated  from  the  semantics  of  the  body  of  the 
loop. 

nn  for  tunat  ely  the  paper  has  im3edded  in  it  examples  in  FORT’^AN. 
However  several  new  s-^atement  types  are  suggested  including 
variants  of  the  DO-WHILE  loop  and  also  a  POSIT-Q HIT- ADMIT 
statement  which  would  be  of  particular  value  in  error  handling 
within  loop  bodies.  The  author  claims  that  by  using  his  suggested 
indentation  rules  and  syntax  one  can  insert  comments  into  any 
programming  language  code  so  th  it  the  code  is  described  in  terms 
of  a  particular  fixed  set  of  statement  types.  The  statement  types 
ni^ed  not  be  implemented  in  the  given  language,  but  the  comments 
would  emulate  the  syntax.  Thus,  the  theory  is,  a  programmer  would 
be  able  to  read  code  in  any  language  f^ven  though  he  might  not  know 
the  particular  language  syntax. 


0LSZEWSKI72  CR2 3,063 

Olszewski, J. ;  On  a  Structure  of  Operating  Systems  Schedulers; 
Proceedings  of  Ifjp  Congress  71,  /ol.  1  (1PT2)  pp. 494-497. 


OFGANICKT2 


CP2  4, 104 


Organick,  E.T.;  The  nulliSS  §istem:  An  Examination  of  its 

Slllioture;  MIT  Press,  Cambridge,  'lassachuset ts  (1  972)  pp.  1-392. 


ORGASS6P  CPI  3,  260  1*1  5 

Orgass,  F.J.,  and  Wai-^e,  W.M.  ;  A  Rase  for  a  Mobile  Programming 
System;  Communicat ions  of  the  AC  1,  vol.12,  no. 9  (Sept.  1969) 
pp. 507-510. 

This  paper  presents  an  algorithm  for  a  macro  processor  which  has 
been  used  as  the  base  of  an  i  mple  inentation,  by  bootstrapping,  of 
processors  for  programming  languavjes.  This  bootstrapping  procedure 
does  not  reguire  a  running  processor  on  the  old  machine  for  its 
implementation.  Hsing  this  algorithm,  transferring  a  language  to 
a  new  machine  has  been  done  withi  i  one  man-week. 


PACKER 70 


CR2J, 150 


Packer,  D.W.;  Effective  Program  Design;  Computers  and  Automation, 
vol.lP,  no. 7  (July  IP'^0)  pp. 37-41, 


PAPNAS69a  CP  18,352  2*9 

Parnas,  D.L.;  On  the  Use  of  Transition  Diagrams  in  the  Design  of  a 
User  Interface  for  an  Interactive  Computer  System;  Proceedings  of 
the  24th  ACM  National  Conference  (1969)  pp. 379-385. 

Parnas  df.scusses  the  design  oc  the  user  interface  for  a  large 
general  purpose  interactive  system.  In  particular,  he  proposes 
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that  a  terminal  connected  to  the  system  should  be  considered  to  be 
in  one  of  a  finite  number  of  stat ?s  and  that  input  messages  can 
cause  transitions  to  other  states.  For  example,  when  power  is 
turned  on,  the  terminal  might  be  in  an  initial  state  where  only  a 
correct  "logon”  will  transfer  it  to  some  state  where  further 
messages  may  be  accep-^ed.  According  to  Parnas,  the  use  of  such  a 
terminal  state  transition  diagram  should  lead  to  a  system  which  is 
better  structured,  easily  documented,  less  likely  to  contain 
errors,  and  perhaps  more  easily  broken  into  pieces  for 
development.  From  the  user’s  viewpoint  the  system  should  be 
easier  to  use,  more  flexible,  and  in  some  cases  more  amenable  to 
his  extension  or  modification. 


PAENAS69b  CRIB, 353 

Parnas,  P.L.;  More  on  Simulation  Languages  and  Design  Methodology 
for  Computer  Systems;  Proceedings  of  the  SJCC,  vol.34  (1969) 
pp. 739-743. 


PARNAS71  5*15 

Parnas,  D.L.;  A  Paradigm  for  Software  Module  Specification  with 
Examples;  Carnegie-Mellon  University,  Department  of  Computer 
Science  (March  1^71)  pp,1-1P. 


PARNAS72b  CP23,949  7*14 

Parnas,  D.L.;  A  Technique  for  Software  Module  Specifications  with 
Examples;  Communications  of  the  ACM,  vol.  15,  no.  5  (May  1972) 
pp. 330-336. 

An  approach  to  wri’ring  software  specifications  for  parts  of 
systems  is  presented.  This  is  an  example  of  Dijkstra’s  principle 
of  non-interference.  The  technique  attempts  to  provide 
specifications  with  sufficient  information  to  allow  interaction  of 
the  parts  only  as  a  whole.  Parnas  suggests  a  structure  where 
specifications  could  be  tested  for  completeness  and  correctness 
before  detailed  coding.  Although  the  idea  is  at  a  young  stage  his 
analysis  to  this  point  is  useful  and  worth  noting. 


PARNAS72C  CE25,1P7  6*14 

Parnas,  D.L. ;  On  the  Criteria  Used  in  Decomposing  Systems  into 
Modul<=s;  Communications  of  the  ACM,  vol.  15,  no.  12  (Dec.  1972) 
pp. 1053- 1058. 

Modularization  involves  decomposition  of  the  problem  into  modules 
corresponding  to  each  major  step  in  the  processing.  Parnas  shows 
by  example  that  modifying  the  data  structure  specifications  (i.e., 
storage  media,  packing  of  information,  input  format)  would  require 
an  extensive  rewriting  of  most  modules.  He  suggests  that  for 
systems  greater  than  5,000-10,000  instructions,  the  criterion  of 
'information  hiding'  be  used  to  guide  decomposition.  Every  module 
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is  charac-^erized  by  a  design  dpci  sion  it  hides  from  all  other 
modules.  Although  efficient  implementation  may  involve  a 
reshuffling  of  the  module  code  to  produce  the  final  system, 
maintaining  both  levels  of  code  wjuld  combat  this  objection. 


PAPNAS72d  CR25,50f^  5*12 

Parnas,  D.L.;  Some  Conclusions  from  an  Fxperiment  in  Software 
Fngineering  Technigues;  Proceedings  of  the  FJCC,  vol.41  (1972) 
pp. 325-329. 

Describes  a  student  group  project  to  test  thf^  methodology  outlined 
by  the  same  author  elsewhere.  Once  the  prcblem  has  been  carefully 
partitioned  into  five  modules,  each  module  was  assigned  to  several 
different  students,  sometimes  with  different  internal 
specifications  for  each  stuient.  Care  is  taken  in  the 
decomposition  to  see  that  details  such  as  data  structures  and 
access  methods  are  ’’known”  to  as  few  modules  as  possible,  usually 
only  one.  The  result  of  the  expeciment,  192  working  combinations 
out  of  a  possible  1024,  is  regarded  as  a  success  considering:  the 
students  were  generally  pcor  programmers,  some  modules  were  not 
finished,  the  language  used  was  W^TFIV,  etc.  The  final  integration 
and  t'^'sting  of  modules  was  done  by  someone  with  ’’absolute  no 
knowl-^dge  of  the  structure  of  any  module.” 


PARNAS72e  CR 25,351  4*16 

Parnas,  D. L.;  Information  Distribution  Aspects  of  Design 
Methodology;  Proceedings  of  IFTP  Congress  71,  vol .  1  (1972) 

pp. 339-344 . 

The  thesis  of  this  paper  is  t.Tat  a  designer  may  retain  tighter 
control  on  the  structure  of  his  system  if  he  controls  the 
distribution  of  information.  Parnas  observes  that  ”a  good 
programmer  makes  us<=-  of  the  useable  information  given  him.”  The 
consequence  is  that  a  good  programmer,  given  all  the  information 
about  the  system  design  will  always  find  some  efficiencies  in  ’’bit 
twiddling.”  The  unfortunate  si 3e  effect  is  that  modules  become 
highly  interconnr-ct^^d,  making  for  nasty  problems  later  in  the 
design.  Restriction  of  informition  distribution  reduces  this 
interdependency.  Information  about  design  decisions  can  now  be 
used,  by  the  designer,  tQ  verify  that  the  code  produced  is 
consistent  with  design  objectives.  Several  good  examples  are 
given  which  support  the  theme  of  the  paper. 


PAKNAS72f  1*15 

Parnas  D,L.;  Pesponse  to  Detested  Errors  in  Well-Structured 
Programs;  Carnegie-Mellon  TTniversity,  Department  of  Computer 
Science,  (July  1972),  pp.1-18. 

The  author’s  main  assumption  is  that  even  well-structured  programs 
will  have  run-time  errors  and  hen  re  reliable  systems  have  to  be 
designed  with  error  handling  anl  self-diagnosis  as  a  fundamental 
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considerat  ion .  '’’he  foremost  problem  with  error  handling  in  a 

structured  program  is  that  th«.>  level  of  abstraction  where  the 
error  is  detected  is  usually  lower  than  the  level  where 
information  for  proper  response  tci  that  error  is  available, 

A  methodology  for  module  desic n  based  on  the  concept  of  the 
software  analog  of  the  hardware  ’’rrap"  is  presented  to  deal  with 
this  problem.  The  ’’software  trap”  technique  allows  error 

conditions  to  be  ’’reflected”  up  through  levels  of  abtraction  while 
maintaining  a  structured  discipline. 

A  detailed  example  of  such  design  is  given  along  with 

suggestions  of  what  type  of  applications  would  benefit  from  the 
discussed  methods. 


PANDELL69  10*1 3 

Randell,  B.T.;  Towards  a  Methodology  of  Computing  System  Design; 
in  Naur,  F.,  and  Randell,  E.  (ed . ) ,  Software  Engineering  (1969) 
pp. 204-208 , 


RHODES70  CB2I,018 

Rhodes,  J.J.;  Modular  Planning  and  Control;  Computer  Bulletin, 
vol.14,  nc.9  (Sept.  1970)  pp.320”325. 


ROSS67  CR2(),013 

Ross,  D,’’’.;  The  AED  Approach  to  G<;neralized  Computer  aided  Design; 
Proceedings  of  the  A.CM  22nd  National  Conference  (1967)  pp.  367-385  , 


SP00NER71  CR2 2,297  1*15 

Spooner  C.R.;  A  Software  Arch..tecture  for  the  70's;  Software  - 
Practice  and  Experience  -  Wiley,  vol.l,  (1971),  pp,5-37. 

The  author  describes  a  framework  for  general  purpose  systems  which 
he  claims  will  be  applicable  through  the  1970s.  He  describes 
Dijkstra’s  ”onion-ring”  approac'ii  to  minimize  the  scope  of  effect 
(or  the  propogation)  of  software  errors.  He  proceeds  to  discuss 
the  use  of  a  ’’kernel”  of  code  as  the  enforcing  mechanism  of 
modularity.  No  module  is  to  rei;eive  more  privileges  than  it 
requires,  thus  limiting  the  scope  of  any  faults.  Desirable 
features  of  future  hardware  implementations  are  listed. 


STEEL65  CP3,551  4^9 

Steel,  T.P.;  The  Development  of  Very  Large  Programs;  Proceedings 
of  IFTP  Congress  1965,  vol.  1  (196  5)  pp.  231-235. 
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STEFL67  CRl3,9iq  3*11 

Steel,  T.P.;  S-»:andards  for  Computers  and  Information  Processing; 
in  Alt,  F.L.,  and  Rubinoff,  M.  (ed,)»  My  ances  in  Compute  rs,  vol.8 
(1867)  pp. 103-152. 

With  such  diversity  in  the  field  of  computer  science,  some  form  of 
unification  must  be  taken.  Standardization  of  the  terminology, 
problem  definition,  programming  languages,  communication 
characteristics  and  physical  (i.e.,  nonelectrical)  characteristics 
of  computers  and  information  processing  devices,  equipment  and 
systems  is  a  must. 

"The  present  chaos  in  programming  languages  is  so  bad  that  it  is 
often  compared  to  the  Tower  of  Babel,  and  any  help  is  worth 
having."  The  complexity  in  attempting  to  standardize  programming 
languages  -  an  almos-^-  imposible  task  -  is  recognized.  The 
developments  and  accomplishments  in  the  universal  standardization 
of  the  languages,  Algol,  Fortran  and  Cobol,  are  related. 

Although  only  twelve  standards  were  produced  in  the  six  years  of 
work,  the  process  should  accelerate  rapidly  if  the  author’s 
surmise  is  correct.  One  should  see  real  and  useful  progress 
toward  the  crea'^ion  of  systematic  standards  to  replace  the  chaotic 
organization  now  prevalent,  particularly  in  the  programming 
languages  area. 


STEVFNS7a  1*15 

Stevens,  W.P.,  layers,  0.  T.  ,  Constantine,  L.L.;  Structured  Design; 
IBM  Systems  iTournal  vol.13,  no. 2,  (1'^74),  pp. 115-139. 

The  authors  provide  th^  suggestion  that  the  notion  of  structured 
programming  be  carried  further,  into  the  design  of  large  systems. 
The  importance  of  module  independence  is  discussed  in  some  depth, 
cons ider a bl<^  time  is  spent  in  the  paper  reviewing  the  degrees  of 
module  "cohe si vne ss"  or  independence. 

The  authors  suggest  that  a  library  of  modules  could  be  built  up  to 
help  reduce  system  generation  cos+’s.  The  gene  ration  of  a  system 
would  be  helped  by  using  pre-written  data  and  environment 
independent  modules  that  require  no  debugging.  System  debugging 
also  would  be  a  less  costly  task  since  after  errors  are  traced 
their  fixes  would  not  have  side-effects  in  other  parts  of  the 
system . 

This  paper  strikes  at  the  core  of  software  engineering  and  re¬ 
iterates  the  basic  principles  of  good  system  design. 


STFACHEY71b  2*14 

Strachey,  c. ;  "he  Interaction  of  Software  Engineering  and  Machine 
Structure;  in  Hugo,  J.S.,  The  Fourth  Infotech,  Ltd., 

Berkshire,  'England  (1971)  pp.  341-  356. 


TALIAFEPR071 


1*10 


Taliaferro,  W.M,;  Modularity.  Tha  Key  to  System  Growth  Potential; 
Software  Practice  and  Experience,  vol.1,  no. 3  (July-Sept.  1971) 
pp. 245-257. 


TSICHRTTZIS72  21*10 

Tsichritzis,  D.;  Lecture  Notes  on  Operating  Systems;  University  of 
Toronto,  Department  of  Computer  Science,  no.  44  (August  1972) 
pp. 1-290 . 

This  readable  set  of  notes  gives  a  great  deal  of  background  and 
information  to  both  the  technical  and  managerial  aspects  of 
software  engineering.  It  also  contains  an  annotated  bibliography. 


TUPSKI68 


Turski,W.M.;  SODA  -  A 
Journal,  vol.11,  no. 


Dual  Activity  Operating  System;  The  Computer 
2  (August  1968)  pp, 148-156. 


ULPTCH70 


11*16 


Ulrich,  W.;  Design 
Systems;  in  Buxton, 
Engineering  Technigues 


of  High  Paliability 
J. N.  and  Pandell, 
,  (1970)  ,  pp.  149-153. 


Continuous 
B,  (ed.)  , 


Oper  ation 
Sof  tware 


The  article  is  a  very  clear  and  concise  report  on  the  design, 
characteristics,  reliability,  problems  and  results  of  a  telephone 
operation  control  system  serving  customers  within  its  locale.  The 
important  issues  of  real-time  considerations,  including 
scheduling,  efficiency,  time  and  recovery,  are  examined  from  a 
trade-off  point  of  view.  The  results  suggest  that  the  trade-offs 
actually  incorporated  form  a  viable  system  with  the  usual 
limitations  of  actual  and  potential  expansion. 


MATTE67  1*10 

ffaite,  W. M,  A  Language  Independent  Macro  Processor; 

Communications  of  the  ACM,  vol.lC,  no. 7  (July  1967)  pp, 433-440, 

A  string-manipulating,  language-independent,  a Imost-machine- 
independent  macro  processor  is  presented  in  this  paper.  The 
output  from  this  macro  processor  is  to  be  presented  to  some 
compiler  or  assembler,  thus  opening  up  many  useful  applications, 
such  as  modifying  a  compiler  without  the  necessity  for  a  complete 
redefinition  of  that  compiler’s  language.  This  paper  can  be 
classified  as  a  high  level  application  to  the  usage  of  macro 
instructions  (in  assembly  language) . 
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WHFELER72 

Wheelt^r,  D.J.;  Assessing  the  Complexity  of  Computer  Systems; 
Proceedings  of  TEIP  Congress  71,  vol,  1  (1972)  pp, 541-544, 


WELLEE73  1*11 

Weller,  F.F.;  Report  of  Session  on  Transferability;  SIGPLAN 
Notices,  vol, 9,  no, 9  (September  1973)  pp,  11-16, 

The  report  discusses  two  aspects  of  portability  "Today’s 
Transf  erabili-*- y  Problem^;"  and  "Future  Systems  Design  for 
Transferability.”  short  discussions  are  given  on  the  followina 
aspects  of  portability:  emulation,  standardization  and 
consideration  of  an  operating  systems  interface  as  an  abstract 
machine.  Similarly  various  opinions  are  given  for  the  future 
design  to  improve  portability  such  as  extensible  languages, 
stressing  flexibility  and  levels  of  transferability. 


WFISSMAN71  2*12 

Weissman,  L,  ;  Software  Interfaces  for  Computer  Systems;  M,S, 
Thesis,  Dniversity  of  Toronto,  Department  of  Computer  Science 
(1971)  pp.1-91. 

Communication  between  program  modules  is  an  area  of  increasing 
importance  and  interest  in  the  design  and  implementation  of 
software  systems,  "^his  communication  is  handled  by  interfaces, 
which  can  be  dealt  with  using  either  the  port  or  structure 
approach.  In  comparing  the  two  approaches  the  structure  approach 
was  chosen  as  the  more  satisfactory.  Problems  exist  with  the 
structure  approach  primarily  because  modules  are  allowed  physical 
access  to  interface  structures.  In  an  attempt  to  solve  some  of 
the  problems  inherent  in  the  structure  approach,  an  interface 
system  has  been  built  for  handling  communication  between  program 
modules.  The  interface  system  gives  the  modules  logical,  rather 
than  physical,  access  to  interface  structures  and  regulates  the 
type  of  access  a  module  may  have  to  a  particular  structure.  The 
interface  system  was  used  in  the  design  and  implementation  of  an 
information  retrieval  system. 


WICHNAN6A  CP17,083 

Wichman,  R. ;  A  Nodular  Operating  System;  Proceedings  of  IFIP 
Congress  1968,  vol,1  (1968)  pp, 548-556, 


TOPICS 

Other  design  papers: 

Arden92,  Bemer69,  Fosdick72,  Int ,Ccmputers70,  McMo niga 1170  , 
Van  Horn68,  wortman72; 
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Machine  design: 

Abrams70,  Parton70,  McFarl.ind70 ,  McKeeinan67,  Strachey71b, 
Wortinan72 ; 

Compiler  design: 

Clark7i,  Conway63,  Floyd67b,  Gauthier70,  GriesTI,  Hendry71, 
F^olt73b,  Horning7tJa,  King71b,,  Knuth71b,  Kulsrud74,  Lock65, 
Lucas73,  Richards71,  Sat+erthwait.e72,  Waite67,  Wells73, 
Wirth7 1c ; 

Operating  system  design: 

Arden69,  Bard71,  Bard72,  B::inch  Hansen70,  Brinch  Hansen73a, 
Brinch  Hansen73b,  Brooks75,  Corbato72,  Cox71,  Dijkstra6Rb, 
nijkstrafiS,  Iampson71,  Lasi;ettre72 ,  Margolin72,  Morris71, 
Needham70a,  Olszewski72,  Organick72,  Pandeil72,  Searaan69, 
Spooner71,  Tsichritzi s72,  UlrLch70,  Wichman68; 

Design  methodologies: 

.MGxarider64,  Bauer72,  Bochmin73b,  Brinch  HansenTO,  Brinch 
Hanseri'^3a,  Brinch  HansGn73b,  Cole73,  Const  antine66 ,  Conway63, 
Corbin71,  Dakin73,  Denil73,  Dijkstra65a,  Dijkstra68b, 
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Steel65,  TrapnellS^,  Tsichri tzis72,  WGidGrman71,  Woodger72, 

yone74,  ZurcherSR; 

Specif leal ions: 

Balze]:71b,  Gu-t-tag7=^,  Hartmaa67,  Kay69,  Liebowitz67,  Odgin73, 
Parnas71,  Parnas72b,  Parr,as72e,  Steel65; 

Modularity: 

Raker’'2b,  Palzer7la,  3auer72,  B“lady71,  Cohen72, 

Const ant ine6f ,  Const antineSS ,  Conway63,  Denil73,  Dennis65, 
DePemerBU,  Pijkstra68b,  Pijkstra69,  Guttag75,  Haney72, 
Hoare72a,  Int.Computers70,  Judd70,  Liskov72,  Madnick69, 
Madnick70,  Maynard72r  McIlroy69,  McKeeman72,  Morris71, 

Morris73a,  Mosedale73,  Myers73,  Odgin73,  Organick72,  Parnas67, 
Parnas69a,  Parras'^  Parnas72b,  Parnas72c,  Parnas72d, 

Pearson73,  Phodes70,  Spooner71,  StevensCh,  Taliaf er ro7 1 , 
We issiiian7  1 ,  Wichroan68; 

Complexity  metrics: 

3elady7l,  Halstead72,  Mills73a,  Wheeler72; 

Integrated  simulation: 

Camp be 1168,  Graham71,  Graham73b,  Parnas67,  Parnas69b, 
Weiderman71,  Zurcher68; 


Standards : 


Brophy70,  Fiont73, 
McIlroy69,  Steel67, 


Fosdick7;', 

Weller73; 


Int.Computers70,  Kerpelman71 


Modi f iabi lit  y  : 


Balzor67,  BalzGr6o,  Balzor7lc,  BauGr72,  Pelady71,  BushnGll71 
Graham71,  Grahani73b,  Gund('rman73,  Lock65,  Madnick69 
Madnick70,  McIlroy69,  Poss67,  Foss70,  Weissinan71,  Wichman68; 


Porta bilit  y: 


Brophy70,  Prown70,  Prown7|,  Cox71,  Evans70,  HaIstGad73 
Haney72,  Jackson70,  McKGe[nan7f),  Poo1g6B,  Pichards71,  Stnith72b 
WaitG70a,  Waite70b. 


Z.1  •  Programming 


Highly  recommendrd  :  Dahl72,  Hi  jk  i:t.ra72a ,  Dijkstra72b,  Hoare72a, 

HoarG73a,  Naur63b,  Wirth71a,  Wirth  71b, 
Wulf"^3 


ALEXANDER'71  2*12 

Alexander,  W.G.;  How  a  Programmin<i  Language  is  Used;  University  of 
Toronto,  Computer  Systems  Research  Group,  no.  10  (February  1972) 

pp.  1  -  1 1  . 

An  analysis  •♦•ool  is  discussed  and  developed  with  which  an  XPL 
programmer  may  determine  the  status  and  dynamic  usage  of  time  and 
the  distibution  of  machine  instruction  usage  for  his  XPL  program. 
Although  limited  in  its  scope  to  one  language  it  is  a  good  example 
of  the  t>pe  of  low  level  analysis  technique  that  could  profitably 
be  applied  to  any  large  programming  project  to  pinpoint 
unsuspected  inefficiencies.  The  particular  implementation  used  is 
slow  because  it  relies  upon  operating  system  interrupts  and 
recoveries  but  does  produce  comprehensive  (although  not 
selectively  controlled)  data  analysis. 


ASHCROFT72  CR24,932  8*11 

Ashcroft,  E.  ,  and  Hanna,  7.;  Th  ?  Translation  of  ’’go  to”  Programs 
to  ’’while"'  Programs;  Proceedings  of  IFIP  Congress  71,  vol,  1 
(1972)  PP.25C-25E. 

This  paper  demonstrates  that  svery  flowchart  program  can  be 
translated  into  an  eguivalent  ’’while”  program  without  ”go  to'’s  and 
proves  that,  in  general,  new  variables  must  be  introduced  to 
preserve  certain  values  or  inform  ition  which  reflects  the  course 
of  computation. 


BAKFR'’2b  CP  25,352  2*10 

Baker,  RiA. ;  How  to  Write  Systems;  Computer  Bulletin,  vol. 16, 
no. 11  (Nov.  1972)  pp. 534-536. 

A  humorous  look  at  avoiding  all  real  problems,  writing  ’’friendly” 
code,  and  muddling  through  the  middle  of  the  project  on  the  way 
from  the  end  to  the  beginning.  The  module  decomposition  criterion 
of  Parnas  reappears  with  the  words  ’’put  the  code  least  likely  to 
succeed  off  by  itself.  Remember  ■"■hat  you  will  be  back  again.” 


EALZEP67  CR15,134  4*9 

Palzer;  Dataless  Programming;  Proceedings  of  the  FJCC, 

vol. 31  (1967)  pp. 535-544. 


In  order  to  provide  for  a  cha  ige  in  operations  on  data,  a  data 
s+-ructure  must  be  highly  modif iab  .e  if  it  is  not  to  result  in 
gross  inefficiencies.  Bal7er  suggests  that  the  definition  of  a 
data  structure  for  a  collection  o  :  objects  should  be  specified 
independently  of  the  operation;  on  that  set.  He  therefore 
proposes  ■♦•he  Pataless  Programming  System  in  which  operations  on 
arrays,  lists  (singly  or  doubly  linked),  rings,  structures, 
composite^;  of  any  of  these,  and  even  user-defined  collections  are 
specified  identically.  The  system  is  extensible;  the  routines 
provided  include  DELETE,  INSERT,  REPLACE,  ADD,  etc.,  allowing  for 
set  operations  such  as  FOR  EACH.,.  IN  THE  DOMAIN...  SUCH  THAT... 


BENSON73  1*14 

Benson,  J.P.;  Structured  Programming  Techniques;  IEEE  Symposium  on 
Computer  Software  Reliability,  New  York  (April  1973)  pp. 143-147. 

The  paper'  attempts  to  answer  the  question  "What  is  structured 
programming?"  by  examining  the  different  meanings  which  have  been 
associated  with  tb.p  term.  Stru>;tured  programming  is  viewed  as  a 
design  methodology  by  examining  t'iie  work  of  E.W.  Dijkstra  and 
H.D.  Mills.  It  is  viewed  as  a  coding  technique  (gotcless 
programming)  in  the  light  of  the  rfork  by  Bohm  and  Jacopini.  The 
paper  serves  as  a  good  (and  brief  introduction  to  the  major  ideas 
of  structured  programming. 


RERGER0N71  6*8 

Bergeron,  R.P.,  Gannon,  J.D.,  and  van  Dam,  A.;  Language  for 
Systems  D<- velopmen  t ;  SIGPLAN  Notices,  vol.6,  no. 9  (October  1971) 
pp. 80 -72 . 


BERGEF0N72  3*11 

Bergeron,  P.D.,  Gannon,  Shscter,  D.?.,  Tompa,  F.W.,  and  van 

Dam,  A.;  Systems  Programming  Langjages;  in  Pubinoff,  N.  (ed.)  , 
Ad van ces  in  Computers,  vol.  12,  Academic  Press,  New  York  (  1972) 
pp. 175-284. 


ROCHMANN73a  CP  26,098  1*1  0 

Bochmann,  G.V.;  Multiple  Exits  from  a  Loop  without  a  Goto; 
Commun  ica'*' ion  s  ot  the  ACM,  vol.  16,  no .  7  (July  197  3)  pp. 44  3-44  4. 

The  author  proposes  another  central  construct  which  outside  of  the 
body  of  a  loop  distinguishes  between  normal  and  abnormal 
termination  of  the  loop.  Thi ;  appears  to  be  a  useful  control 
structure  extendable  to  the  searching  cf  linked  lists. 
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DOCHMANN73b 

Bochmann,  G.V,;  Hierarchical  Lang 
vol.8,  no. 9,  (September  1973)  pp. 

The  author  describes  a  basi 
operating  systems  and  other  relat 
basic  language,  (machine  indep 
different  machine)  a  hierarchy  of 
which  is  written  in  the  previous 
primitives  for  parallel  processes 
again  presumably  for  interrupts. 


BRTNCH  HANSEN72a 

Brinch  Hansen,  P. ;  Structured  Hul 
pp,  574-578 , 

The  author  presents  an  extens 
PASCAL  to  permit  and  control  mu 
manner.  He  introduces  the  concu 
COEND  and  discusses  mutually  excl 
permits  process  communication  v 
regions,”  introducing  a  REGION  gr 
depending  on  a  shared  variabl 
concept  of  an  event  variable  wh 
statement  within  a  critical  reg 
critical  region  based  on  the  same 
of  this  structure  to  these  cone 
of  the  programmer  and  eases  proof 


1*7 

uage  Definition;  SIGPLAN  Notices, 
50-51 . 

<:  methodology  for  implementing 

ed  programs.  Starting  from  a 
(indent  but  implemented  on  each 
languages  is  described  each  of 
Language.  Only  when  implementing 
does  the  real  machine  surface 
liming,  etc. 


1=<‘15 

liprogramming ;  CACM  15,7,  (1  972), 


Lon  to  the  programming  language 
Lt iprogramming  in  a  structured 
Trent  statement  COBEGIN  S1,S2,S3, 
usive  operations  S1,  S2,..  He 

La  shared  variables  and  "critical 
oup  not  unlike  a  DO  group,  but 
e.  He  continues  from  here  to  the 
ich  can  be  used  in  an  AWAIT 
Lon,  or  by  a  CAOSE  statement  in  a 
shared  variable.  The  addition 
?pts  greatly  clarifies  the  intent 
of  correctness. 


BRINCH  HANSEN72b 


1*16 


Brinch  Hansen,  P.  ;  A 
Acta  Informatica,  Vol.1, 


Comparison  of  Two  Synchronizing  Concepts; 
(1^72),  pp. 190-199. 


The  author  examines  the  relative  merits  of  two  synchroniz 
methods,  namely,  semaphores,  and  conditional  critical  reg 
The  application  of  the  two  methods  is  outlined  on  the  wr 
reader  problem  and  proofs  of  these  applications  are  presented 

The  conclusions  the  author  reaches  suggest  that  the  ea 
applicability  of  either  method  depends  to  a  large  degree  on 
application.  Also  the  suggestion  is  made  that  the  cendit 
critical  region  concept  be  incDrporated  as  a  primitive 
languages  that  are  designed  for  applications  involving  par 
processes, 
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Brinch  Hansen,  P.;  02§tatin_3  Systems  P  rinci  pies;  Pren  t  ice- Hall , 
Inc.,  Englewood  Cliffs,  N.J.  (1973)  pp. 1-366. 
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CR2(),  231 


2*10 


Brophy,  H.F,;  Improving  ?rogj:amming  Performance;  Australian 
Computer  Journal,  vol.2,  no. 2  (May  1970)  pp, 66-70. 


"The  purpose  of 
human  el^^iient  of 
Erophy  discusses 
opposed  to  buildi 
improvement  he  su 
already  availabl 
Generalized  sys 
reprogramming  to 
Erophy  suggests 
more  meaningful 
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developmei t.  Fi 
documentation,  et 
different  progra 
comouter  software 


this  paper  is 
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variable  names 
the  program,  an 
utilizing  the 
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c.,  are  proposed 
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to  shift  the  spotlight  on  to  the 
relationship."  In  this  article, 
easing  programming  performance  as 
•cter  machines.  To  achieve  an 
:  better  tools,  the  better  use  of 
•:.he  imposition  of  standards. 
,5ted  that  will  avoid  needless 
n  cf  a  previously  solved  problem, 
sion  logic  tables,  more  comments, 

,  better  documentation  cross 
d  the  use  of  programming  teams  as 
existing  tools  of  software 
;  in  language,  data  structures, 
to  improve  communication  between 
id  to  improve  the  portability  of 


EeOWN70 


8*11 


Brown,  W.S.;  Software  Portabili  ly ;  in  Buxton,  J.N.,  and  Randell, 
B.  (ed. ) ,  Software  Engineering  Techniques  (1970)  pp.80-BU. 

There  can  be  no  dispute  that  s  iftware  portability  is  one  of  the 
central  problems  in  software  enqiieering.  Brown's  solution  to  the 
problem  is  to  write  all  his  software  (ALTRAN  F)  in  FORTRAN  with  a 
macro  processor  (M6)  which  accomoiates  various  dialects  of  FORTRAN 
(e.g.  INTEGER  *  2  in  360  FOETRAN).  This  is  perhaps  sufficient 
comment  on  the  state  of  the  art  of  software  portability. 


BP0WN7 1 
Brown , 


P.  J. 


The  ML/I  Macro  Processor: 


Guide;  Computing  Laboratory,  Univsrsity 
(October  1971),  pp.1-16. 


of 


1*15 

A  Simple  Introductory 
Kent  at  Canterbury, 


ML/J  is  a 
This  manual 


general 

describes 


purpose  ma::ro  processor;  possibly  the  best, 
much  of  ML/T  and  shows  examples  of  its  use. 
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G<=neral  purpose  mac ro- proce ssors  can  be  used  to  extend  languages 
(e.g.  extending  FORTPAN  with  a  while  statement),  to  perform 
simple  transformations  on  text,  or  to  allow  shorthand  for  text 
entry.  This  paper  is  valuable  as  an  introduction  to  general 
purpose  macro- processors. 


BP0WN72  4«7 

Brown,  G.  deW. ;  The  Forum:  Programming,  the  Quiet  Revolution; 
Datamation,  vol.19,  no, 3  (March  1972)  pp. 147-150, 

In  the  sixties  programmers  were  considered  by  the  public  and 
themselves  as  heroes,  capable  of  solving  any  problem.  In  order  to 
face  new,  complex  problems  s ucce ssf ull y,  programmers  must  adopt  a 
more  disciplined  attitude,  and  be  more  concerned  with  quality. 


CHEATHAM72a  CF25,353  1*8 

Cheatham,  T."^.;  The  Recent  Evolution  of  Programming  Languages; 
Proceedings  of  IFIP  Congress  1971,  vol.  1  (1972)  pp. 298-313. 


CLARKR1  19*13 

Clark,  P.L,,  and  Horning,  J.J. ;  The  System  Language  for  Project 
SUE;  SIGPL?!.N  Notices,  vol. 6,  no. 9  (October  1971)  pp,  79-88  . 

The  authors  motivate  the  discussion  of  the  System  Language  by 
describing  the  Project  SUE  context  which  produced  it.  They  -^hen 
list  the  languaae  design  criteria,  emphasizing  structure  (of 
program,  data,  and  paragraphing),  efficiency  (of  compilation, 
execution,  and  implementation),  and  modifiability. 

The  fea'^’-ures  of  the  language  are  listed  and  described  under  the 
headings  Compilation  Structures,  Data  Structures,  and  Program 
Structures.  Ar.  example  program  is  includad  to  illustrate  these 
s-^. ruc-^ures,  as  well  as  the  paragraphing  of  the  language. 

CLARK73  1*18 

Clark,  3.L.  and  Horning,  J.J.;  Reflections  on  a  Language  Design<=^d 
to  Write  an  Operating  System;  ACM  SIGPLAN  Notices,  Vol. 8,  No. 9, 
(September  1973),  pp. 52-58. 

The  authors  express  •'■.heir  opinions  on  the  crucial  issues  in 
design  of  a  high-level  system  language,  based  on  experience  wi-'-h 
Project  SUE.  Various  advantages  of  languages  emphasizing 
structur<=‘  (program  and  data),  redundancy,  and  efficiency,  over 
•'■  rad i tiona lly  used  machine  dependent  language  are  outlined.  An 
example  program  is  included  at  the  end  to  illustrate  the  above 
points. 
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COHEN'74  1*15 

Cohen,  J.,  and  Zuckerman,  C, ;  Two  Languages  For  Estimating  Proqram 
Efficiency;  CACM,  (June  1974),  pp,301-10fl. 


COLE73  1*12 

Cole,  N.M.,  and  Seikel,  Solving  a  Software  resign  Problem 

Psing  Plain  English;  Datamation,  vol,19,  no, 10  (October  1973) 

pp, 101-106, 

This  article  describes  a  method  of  top-down  program  design.  Plain 
English  is  not  really  used,  nut  rather  a  high-level  macro 
language.  The  macros  are  written  by  top-level  programmers 
familiar  with  the  system,  and  the  information  content  of  the 
macros  is  such  ^hat  low-level  programmers,  who  lack  the  detailed 
knowledge  of  the  system,  can  flowchart  and  code  the  program 
without  too  much  difficulty.  The  authors  claim  savings  in  time, 
increased  efficiency,  and  more  effective  use  of  programmer 
resources 


CONSTANTINE68  CR14,16R  2*8 

Constantine,  L,L,;  The  Programming  Profession,  Programming  Theory, 
and  Programming  Education;  Computers  and  Automation,  vol,17,  no, 2 
(February  1^6^)  pp, 14-19, 

The  classic  challenge  of  programming  has  been  that  it  lacks  (1)  an 
ordered  body  of  knowledge,  (2)  active  interaction  between  the 
practitioners  in  the  field  and  that  body  of  knowledge  and  (3)  a 
systematic  educational  approach  for  imparting  that  knowledge  to 
new  PHtrants  in  the  field.  The  author  maintains  that  the  body  of 
knowl'^dge  of  programming  pxists,  but  not  in  an  integrated  form. 
He  proposes  two  theories  distinct  from  each  other,  the  theory  of 
programs  and  ^ho  process  theory  of  programming. 

Programs  consis*  of  a  set  of  ordered  statements,  Therp  is  a 
structure  to  programs  determined  by  the  relation  of  the 
statements.  Programming  is  a  process  that  involves  human 
creativity.  Nevertheless,  it  is  governed  by  rules,  perhaps 
informal,  that  are  usually  followed.  Much  more  is  known  about 
programs  and  programming  than  is  being  taught.  The  problem  is 
that  most  the  knowledge  is  gained  in  industry  and  most  of  the 
teaching  is  bpina  done  in  the  universities.  The  author  maintains 
that  a  lack  of  communication  between  industry  and  the  universities 
results  in  the  computer  scientist  obtaining  an  incomplete 
education.  He  proposes  a  program  that  is  intended  to  remedy  this 
situa-*- ion  , 


CONWAY63  CPS, 024 

Conway,  !1,E,;  Ppsign  of  a  Seperable  Transition  Diagram  Compiler; 
Communications  of  the  Z-iCM ,  vol,  8  no, 7  (July  1963)  pp,  396-408, 


C0RBATO6<5 


CR1" , 694 


6«  1  .3 


Corbato,  F.J,;  PI/T  as  a  Tool  for  .System  Programminq;  Datamation, 
vol,15,  no. 5  (May  1969)  pp. 68-76. 

One  of  the  more  iinportan'*'  aspects  of  the  MfJLTICS  effort  was  the 
decision  to  use  ^L/J  as  the  systems  implementation  languatje.  This 
paper  discusses  the  reasons  for  choosing  a  high  level  language  for 
systems  programminq  and  the  reasons  why  PL/I  in  particular  was 
chosen  for  MUL'^TCS.  The  difficulties  in  implementing  the  language 
and  some  of  the  evils  of  PL/1  in  such  an  environment  are 
discussed.  That  Honeywell  intends  to  make  the  system  commercially 
available  attes-^s  to  either  the  ccrrectness  of  their  assumptions 
or  extreme  perseverenc^  in  the  face  of  adversity. 


C0RBIN71  1*15 

Corbin,  K.,  Corwin,  W.,  Goodman,  R.,  Hyde,  E.  ,  Kramer,  K ,,  ,  Werrae, 
E.,  Wulf,  W. ;  A  Software  Laboratory  Preliminary  Report;  Carnegie- 
Mellon  nniversi-'-y  Computer  Science  Dept.  Technical  Report, 
(August  1871) , 

This  paper  describes  a  system  which  allows  students  and 
researchers  to  construct  software  systems.  Systems  are  to  be 
built  by  ’’plugging  together”  modules  in  a  data-flow  manner.  This 
system  would  have  characteristics  like  the  Data-flow  Programming 
Language  described  in  f  Kosinski7 the  ’’macro  modules”  of  Clark, 
and  raessacies  between  processes,  ?,s  in  the  RC4000  system.  An 
implementcition  strategy  and  a  kernel  are  presented  which  support 
this  systc^m. 


DAHL'7  2  1*19 

Dahl,  O.J.,  and  Hoar° ,  C.A.P.;  Hi  ‘rarchical  Program  Structures;  in 
Dahl,  O.J.,,  Dijkstra,  E.W.,  and  Hoare,  C.A.R.(ed.);  Structured 

Academic  Press,  London  (1  972),  pp.  175-220. 

This  paper  describes  an  elegant  merging  of  structured  data  and 
control  cc.ncepts  in  the  ’’class”  construct  of  the  SIMULA  67 
language.  Examples  are  given  to  show  how  a  class  may  be  used  to 
represent  a  general  data  structure  and  operations  on  it  as  unified 
concept,  and  how  specific  instances  of  the  structure  may  be 
generated.  Demonstration  is  also  given  of  the  use  of  the  class 
concept  for  the  implementation  :f  coroutines.  The  exposition  is 
somewhat  weakened  by  the  stress  p. Laced  on  the  use  of  the  language 
for  simulation  studies,  and  b /  the  fact  that  the  language 
designers  felt  it  necessary  to  make  variables  of  a  class  object 
accessible  from  outside  the  object.  Nonetheless,  the  concepts 
presented  are  certainly  worthy  of  further  attention,  particularly 
with  a  vif w  toward  restoring  locality  of  data  to  the  class. 
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DIJKSTRA62 


CRo,6U9 


6*16 


Diikstra,  R.W.;  Some  Medita  :ions  on  Advanced  Programming; 
Proceedings  of  IPTP  Congress  1962  (1962)  pp. 535-538, 


In  this  paper  Dijkstra  reflects  o 
bad  architecture  of  past  mach 
available  commercially-produced 
since  programming  is  equivalent 
should  accept  the  responsibility 
exploring  them  in  software,  ALGOL 
which  provoked  considerable  ef 
considerable  thought  about  progr 
programming  is  criticized  in 
Correctness,  reliability  and  thei 
Diikstra  concludes  with  a  desire 
his-tools  relationship  develop. 


,1  several  topics.  He  reviews  the 
Lnes  and  of  the  then  largely 
machines.  He  points  out  that 
:o  machine  design,  programmers 
of  influencing  future  designs  by 
60  is  mentioned  as  an  entity 
rort  in  translator  writing  and 
imming  languages.  Puzzle-minded 
Favor  of  a  systematic  approach, 
:  demonstration  are  emphasized, 
:o  see  a  symbiotic  craft sman-and- 


DIJKSTRA65a  C39,006  13*17 

Dijkstra,  E.W,;  Programming  Co  isidered  as  a  Human  Activity; 
Proceedings  of  IFIP  Congress  1965,  vol, 1  (1965)  pp, 213-217, 

The  main  thrust  of  this  paper  is  that  the  programmer  and  his  mind 
are  an  important  part  of  the  computing  process.  The  use  of  these 
parts  of  the  process  is  not  necessarily  optimized  by  making  poorer 
use  of  the  machine.  Father  there  can  be  a  gain  in  efficiency  of 
usage  of  the  machine  by  using  top-dcwn,  GOTO-less  program 
structuring  which  is  more  easily  created  and  understood  by  humans. 

The  paper  suggests  that  investigation  be  done  to  see  to  what 
degree  the  goals  of  humans  and  the  characteristics  of  the  machine 
are  parallel,  and  that  we  do  not  flatly  assume  that  these  are 
opposites. 

The  author  asserts  that  elegante  leads  to  desirable  features  of 
programming  lancruages,  A.s  the  title  implies,  he  approaches 
programming  through  the  basic  pattern  of  human  understanding.  From 
this  attitude  he  criticizes  programming  to  date  and  describes  more 
natural  and  elegant  structures, 

Dijkstra  gives  a  clear  statement  of  successive  refinement  of  a 
problem,  emphasizing  (1)  division  into  parts,  (2)  the  parts 
together  form  the  whole,  aid  (3)  the  principle  of  non- 
inter  fereiice  .  Here  also  are  his  classic  arguments  for  program 
correctnejjs  and  against  the  "Gvl-TO.”  He  proposes  four  desirable 
language  features  and  concludes  that  an  area  for  work  is  that  of 
the  compromises  of  efficency  against  convenience. 


DIJKSTRA68a  19*16 

Dijkstra,  E,W,;  Go  To  Statement  Cnnsidered  Harmful;  Ccramunica tions 
of  the  ACM,  vol. 11,  no. 3  (Mar.  1  969)  pp,  147-148. 
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The  concept  of  independent  co-ordinates  with  which  to  describe  the 
progress  of  a  process  is  discussed.  Such  co-ordinates  cannot  be 
found  if  unstructured  control  transfers  are  allowed  in  programming 
languages.  Suggestions  are  made  for  alternative  constructions 
that  are  both  flexible  and  structured  so  that  an  independent  co¬ 
ordinate  system  can  be  maintained. 


DIJKSTRA6RC  13*9 

Dijkstra,  F.H.;  Co-operating  Secuential  Processes;  In  Genuys,  p. 
(ed.).  Programming  L^rguages,  Academic  Press  (1968)  pp. 43-112. 

The  use  of  semaphores  in  mutual  exclusion  and  process 
synchronization  is  discussed  and  techniques  for  implementation  co¬ 
operation  among  parallel  processes  are  examined  in  detail.  A 
proof  of  correctness  is  presented  for  the  message  interpreter  for 
the  T.H.E.  System  and  finally  t\ e  Bankers  Algorithm  is  discussed 
as  a  means  of  preven-^ing  deadlock. 


DIJKSTPA70  18*17 

bijkstra,  E.W.;  Structured  Programming;  in  Buxton,  iJ.N. ,  and 
Randell,  P.  (ed.).  Software  Engineering  Techniques  (1970)  pp.84- 
87. 

A  discussion  of  the  amount  of  reasoning  required  to  understand  an 
arbitrary  program  leads  to  the  conclusion  that  the  production  of  a 
correct  program  can  be  accomplished  most  easily  by  successive 
refinement  of  an  abstract  program. 


DIJKSTRA71b  11*18 

Dijkstra,  "^.W.;  A  Short  Introdnction  to  the  Art  of  Programming; 
Eindhoven  fJniversity,  no.  EWD316  (August  1971)  pp.1-97. 


DTJKSTRA72a  CE^4,552  27*18 

Dijkstra,  E.W.;  The  Humble  Programmer;  Communications  of  the  ACM, 
vol.  15,  no.  10  (October  1*572)  pf.  859-866; 

The  author  reflects  on  the  historical  development  of  procfram  ming . 
Initial  hardware  constraints  and  the  nature  of  the  slowly 
developing  field  resulted  in  puzzle- minded  programmers  who 
optimized  the  computing  process.  The  introduction  of  second  and 
third  generation  computers  only  heightened  the  problems. 

In  looking  to  the  future  he  foresees  that  projects  that  are  of 
limited  size  will  be  done  with  much  less  #=ffort  and  many  fewer 
bugs.  This  will  be  accomplished  by  limiting  ourselves  to 
"intellectually  manageable  prograns."  A  number  of  reasons  for  this 
are  given,  as  well  as  some  impedinents.  To  be  humble  programmers, 
it  is  necessary  to  realize  the  magnitude  of  the  problems,  the 
usefulness  of  the  tools,  and  the  linitaticns  of  the  human  mind. 


DIJKSTRA72b 


CP: 6,364 


15*^9 


Dijkstra,  R.W.,  and  Dahl,  O.J.,  and  Hoare,  C.A.R.;  Structured 
Proqratnmi ng;  Academic  Press,  N.Y.,  (1972),  pp.1-82. 

This  first  section  of  the  book  is  by  Dijkstra,  and  entitled  “Notes 
on  Structured  Programming . “  It  is,  an  informal  set  of  notes  he 
wrote  to  himself  while  contempla i  ing  the  problems  of  programming. 
The  notes  are  informal  in  that  they  tend  to  meander  through  the 
topic,  but  display  considerable  formality  in  the  presentation  of 
any  one  idea.  The  initial  comments  on  the  probability  of  a 
program  being  correct  are  based  on  shaky  premises.  The  sections 
on  top-down  programming  are  worth\hile.  The  last  section  seems 
designed  to  convince  the  reader  that  programming  style  can  be 
taught  successfully. 


EBSH0V72  CR2i,022  3*14 

Ershov,  A.P.;  Aesthetics  and  the  Human  Factor  in  Programming; 
Communications  of  the  ACM,  vol.  ‘5,  no.  7  (July  1972)  pp.SOI- 
505. 


FALKOFE70  1*11 

Falkoff,  A.D,;  Criteria  for  a  System  Design  Language;  in  Buxton, 
J.N,,  and  Pandell,  B.  (ed . )  ,  Jioftware  Engineering  Techniques 
(1970)  pp. 88-93. 


FELDMAN68  CPlt,729  7*11 

Feldman,  J. ,  and  Gries,  D.;  Translator  Writing  Systems; 
Communications  of  the  ACM,  vol. 11,  no. 2  (Feb.  1968)  pp. 77-113. 

A  survey  of  the  state-of-the-art  in  translator  writing  systems  up 
to  1968.  It  is  a  useful  discussion  on  the  automation  of  writing 
translators  for  programming  languages  and  includes  a  formal  study 
of  syntax. 


FTSHFP72  2*18 

Fisher,  D.A.;  7-  Survey  of  Coiitrol  Structures  in  Programming 

Languages;  SIGPLAN  Notices,  vol.  7,  no.  11  (November  1972)  pp.  1- 
14. 

This  paper  examines  the  convrol  structures  of  programming 
languages  and  how  the  constructs  are  developed.  Progress  has  been 
made  by  sp<=c  ializat  i  on  through  cromposition  of  a  few  very  general 
primitive  operations.  The  dominance  of  the  underlying  sequential 
machine  is  apparer.'*’  throughout  ihis  process.  In  some  areas  -^his 
specialization  has  lead  to  clarity  and  efficiency,  while  in  others 
the  accompanying  loss  of  generalit.y  has  had  the  opposite  effect. 


GANN0N75 


1*20 


Gannon,  J.D.  and  Horning,  J,J.;  The  Impact  of  Language  Design  on 
the  Production  of  Feliahle  Sof  .ware;  in  Three  Approaches  to 
Reliable  Software:  Language  Dej^ign,  Dyadic  Specification,  and 
Complementary  Semantics;  Technical  Report  44,  Computer  Systems 
Research  Group,  Hniversity  of  Toronto,  (January  197S), 

Gannon  and  Horning  investigate  the  effects  of  language  design 
d'^cisions  on  the  error  rate  of  programmers.  Th^^y  first  sel^^c*-  a 
small  programming  language  and  identify  nine  (nearly)  unrelated 
error-prone  constructs.  They  ..-edesign  these  constructs  in 
accordance  with  intuition  and  human  learning  principles,  and 
incorporate  the  modified  constructs  in  a  new  dialect  of  the 
language.  In  a  carefully  controlled  experiment,  programmers  are 
found  to  make  significantly  fewer  (and  less  severe  in  terms  of 
persistence)  errors  in  the  modified  dialect  than  in  the  original 
language.  This  paper  is  excellent,  and  the  results  are  of 
immediate  practical  value. 


GARWTCK6 1 


Garwick,  J.V.;  The  Programming  of  Large  Logical  Problems;  BIT, 
vol.1,  no.  1  (1961)  pp. 21-26. 

By  ’’large  logical  problems”  Garwick  means  programs  of  substantial 
size  dealing  with  non-numer ical  problems.  He  states  that  the 
usual  undisciplined  approach  to  programming  is  unsatisfactory  and 
makes  suggestions  in  the  areas  of  planning,  testing,  and 
documentation  to  improve  the  programming  process.  His  suggestions 
for  planning  sound  like  the  beginnings  of  the  ideas  of  stepwise 
refinement  and  the  use  of  a  programming  language  (Algol)  as  a 
design  tool. 


GRAHAM70 

Graham,  E;.M.;  The  Hse  of  Higi  Level  Languages  for  Systems 
Programming;  Proceedings  of  Invititional  Workshop  on  Networks  of 
Computers  (October  1970). 


GRIFFITH7:!  1*11 

Griffith,  P.F.,  and  Henry,  R.M.;  ^n  Investigatory  Study  into  Human 
Problem  Solving  Capabilities  as  They  Relate  to  Programmer 
Efficiency;  SIGCPR  Bulletin,  vol. 3,  no. 3  (1972)  pp. 10-14. 

This  paper  is  detailed  description  of  a  research  study 
investigating  programer  efficiency  as  it  relates  to  maintaining 
varying  numbers  of  COBOL  data  processing  programs.  The  results 
showed  that  greater  programmer  efficiency  occurred  in  solving  3 
problems  in  parallel  than  solving  3  problems  sequentially.  The 
sample  size  was  18  subjects.  Hence  the  results  are  at  best 
marginally  significant.  These  results  seem  contrary  to  other 
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results  notpfl  in  'current  literature',  but  did  generate  much 
enthusiasm  in  the  subjects  doing  the  parallel  processing. 


GPTES71 

Cries,  D,;  Compiler  Construction  for  Digital  Computer s ;  Wiley, 
N.y.  (1^71)  pp.  1-493. 


GFTES74  1*17 

Cries,  D.;  On  Structured  Programming  -  A  Reply  to  Smoliar; 
Communications  of  the  ACM,  vol.17,  no. 11,  (November  1974]  ,  pD,655- 
6S7. 

A  well  reasoned  well  stated  attempt  to  explain  the  connotations  of 
the  term  "s'-ructured  programming.” 


HANSEN71  CP22,792 

Hansen,  W.J.;  User  Engineering  Principles  for  Interactiv<=  Systems; 
Proceedings  of  the  SJCC,  vol.  38  (1971)  pp. 523-532. 


HENDEFSON72  9*14 

Henderson,  P.,  and  Snowdon,  P.;  An  Experiment  in  Structured 
Programming;  PIT,  vol.  12  (1972)  pp.  33-53. 

An  example  of  top-down  d<=velopraent  of  a  program  is  given.  (The 
example  is  a  program  to  process  telegrams).  Although  carefully 
constructed  and  correct  in  appearance,  the  program  contains  an 
error.  The  process  of  using  the  structure  to  locate  and  correct 
the  error  (as  opposed  to  patching  the  final  program)  is  examined 
to  see  if  error  loca*-ion  is  improved  by  the  structuring.  In 
addition,  some  pitfalls  of  structured  programming  are  described. 
This  paper  is  a  good  antidote  to  unalloyed  euphoria  about 
structured  programming. 


HENDPy71 


Hendry,  0.;  Benefits  For  User  and 
Approach  to  Compiler  Design;  in  Hugo, 
Generation ,  Infotech,  L-^d.,  Berkshire, 


Producer  of  an 
iT.S.  (ed.), 
England  (1971) 


Engineering 
The  fourth 
pp. 299-312. 


HENPICKSEN72 


CP23,B05 


1’f'l  2 


Henrickse  ?. , 
Efficiency  in 
vol.  40  (  1972) 


J.O.,  and  Merwin,  R.E.;  Programming  Language 
Real-Time  Software  Systems;  Proceedings  of  the  SJCC, 
pp. 155- 161 . 


This  paper  attempts  to  examine  how  the  trade-offs  between 
efficiency  of  genera-i-ed  code,  space  reguirements,  run  time  (speed) 
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and  programmer-wr itten  statement.;  are  affected  by  the  choice  of  a 
programming  language.  This  paper  reports  the  results  of 
implementing  a  number  of  well-defined  algorithms  in  each  of 
several  languages,  on  a  number  of  different  machines.  The  authors 
draw  seemingly  warranted  conclusions. 


H0ARE6'?  CEld,32B  7*14 

Hoare,  C.A.R.;  I\n  Axiomatic  B.isis  for  Computer  Programming; 
Communications  of  the  ACM,  vol.12,,  no.  10,  (October  1969),  pp.576- 

5B0. 

Working  with  a  simple  set  of  operations  on  data  (integer  addition, 
subtraction,  and  multiplication),  Hoare  examines  various  axioms 
which  may  be  added  to  the  axioms  of  arithmetic  to  cover 
peculiarities  of  computer  operations,  using  overflow  as  an 
example.  He  then  introduces  an  axiom  to  deal  with  the  assignment 
operation,  and  two  rules  of  inference.  Using  these  axioms  and 
inference  rules,  he  investigates  formal  statements  which  can  be 
made  about  sequential  operations  and  iteration,  and  gives  an 
example  of  the  application  of  the  rules  to  a  simple  program. 
(Regrettably,  no  rule  is  proposed  for  a  conditional  statement, 
which  would  complete  a  minima^,  set  of  control  constructs.  )  The 
paper  concludes  with  a  consideration  of  the  limitations  of  the 
study,  particularly  the  lack  of  a  basis  for  proof  of  program 
termination,  and  some  cogent  arguments  for  the  desirability  of 
using  formal  techniques  for  language  design  and  proofs  of  program 
correctness. 


H0ARE71a  CR  !3,6iJ7  1*15 

Hoare,  C.A.R.;  Procedures  and  P.irameters:  An  Axiomatic  Approach; 
Symposium  on  Semantics  of  Algoritlimic  Languages,  Springer  Verlaq, 
Berlin  (1971)  pp.  102- 1 16. 

The  author  develops  a  formalii^m  which  facilitates  proofs  of 
program  correctness.  He  needs  to  impose  a  restriction  on 
procedure  calls,  which  is,  hoi/ever,  a  desirable  programming 
feature. 


HOAEE72a  3t15 

Hoare,  C.A.P.;  Notes  on  Data  Structuring;  in  Dahl,  O.J.,  Dijkstra, 
E.W.,  and  Hoare,  C.A. P.;  Structured  Programming ;  Academic  Press, 
New  York  (June  19*^2)  pp.B3-174. 

The  author  motivates  the  monociraph  by  presenting  the  notion  of 
abstraction,  illustrated  by  real-world  and  programming  language 
examples.  Within  this  setting  thf'  notion  of  a  type  is  given,  with 
special  attention  devoted  to  the  operations  defined  for  values  of 
a  type.  A  detailed  description  ol  structuring  operations  on  types 
is  given,  emphasizing  the  meaiiing  of  the  structures,  and 
manipulations  and  representations  of  values  of  the  structures.  An 
example  illustrates  the  use  of  the  structuring  operations  to 
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r^finp  abstract  types.  Finally,  an  axioma ti’za t ion  of  the  types  is 
presented , 


HOASE72b  CP25,9a4  1*17 

Hoare,  C.A.R.;  Towards  a  Theory  of  Parallel  Programming;  in  Hoare, 
C.A.R.  and  Perrott,  E.H.(eds.),  Ope  rating  Systems  hn  i  2il£s , 
Academic  Press,  N.Y.  (1972),  pp. 61-71. 

This  paper  begins  with  a  brief  discussion  of  objectives  to  be  met 
in  designing  a  parallel  processing  feature  for  high-level 
language:  compile-time  checks  to  avoid  time-dependent  errors, 
generation  of  efficient  code,  and  constructs  which  are  both 
conceptually  simple  and  widely  applicable. 

Constructs  are  proposed  for  defiling  parallel  processes,  defining 
resources,  and  using  them  for  intsrprocess  communication.  These 
constructs  appear  to  satisfy  the  stated  objectives  quite  well, 
although  the  notation  for  the  first  seems  rather  difficult  to  read 
and  prone  to  coding  errors;  tie  semantics  of  the  third  allow  a 
definite  possibility  for  "bus y-wa  it ing , ”  something  which  might  be 
avoided  by  a  more  sophisticated  enqueuing  of  blocked  processes  on 
conditions  rather  than  on  simple  resource  availability. 

Two  other  useful  concepts  are  introduced:  the  capability  of 
partitioning  arrays  to  allow  simultaneous  access  by  more  than  one 
process,  and  the  abili'^y  to  define  arrays  of  resources. 


H0APET3a  2*20 

Roare,  C.A.R.  ;  Hints  on  Programmi  ig  Language  Design;  ACM  Symposium 
on  the  Principles  of  Programming  Languages,  Poston  (October  1973), 
pp . 1 -  30 . 

This  highly  readable  and  fregu  ?ntly  entertaining  article  begins 
with  the  observation  that  "a  programming  language  is  a  tool  which 
should  as;sist  the  programmer  in  the  most  difficult  aspects  of  his 
art,  namely  program  design,  documentation  and  debugging." 

In  this  c;ontext,  Hoare  reflects  ;n  numerous  language  and  compiler 
features.  He  aroues  that  a  good  Language  should  encourage  simple 
and  readable  programs,  and  have  i  fast  compiler  which  can  produce 
secure  and  efficient  code.  He  sugg<^sts  that  a  good  many  of  the 
newer  larguages  may  actually  make  the  programmer’s  task  more 
dif f icult . 

One  is  leminded  -^.hat  an  extreiiiely  important  part  of  the  design 
process  is:  the  decision  of  what  to  omit,  an  aspect  which  appears 
rarely  to  have  received  adequate  attention. 


HOARE73b  2*16 

Hoare,  C.A.P.;  Recursive  Data  Structures;  Stanford  University, 
Computer  Science  Dept.,  S TAN-CS-7 5-400 ,  (October  1973),  pp.1-32. 
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The  author  proposes  an  extension  •*  o  programming  languages  to  allow 
data  structures  to  be  defined  by  lecursion.  The  formalism  is  to 
define  a  "type"  in  terms  cf  a  recursive  application  of 
"generators"  over  a  type  list.  Manipulation  cf  these  structures 
is  confined  to  further  applicatiors  of  the  generators  on  instances 
of  the  defined  type. 

The  claim  is  made  that  such  a  schema  would  eliminate  the  problems 
associated  with  the  PL/1  or  AlgolfS  pointer  type.  The  pointer 
type  is  cited  as  the  data  structures  equivalent  of  the  "go  to"  in 
control  s -t-ruct ures . 

The  author  goes  on  to  define  1  is  new  construct  in  an  axiomatic 
fashion  and  to  suggest  impl^menta ■*  ion  methods. 


HOARE73C  1*16 

Hoare,  C.A.P.,  and  wirth,  N. ;  An  Axiomatic  Definition  of  the 
Programming  Language  PASCAL;  Acta  Informatica  2,  (1973),  pp.335- 
3  55. 

An  attempt  to  describe  formally  the  s<=‘mantics  of  the  language 
PASCAL.  The  basis  for  this  is  the  approach  expounded  in  "An 
Axiomatic  Basis  for  Compute!'  Programming"  [Hoare69],  The 
definition  is  quite  useful  but  it  is  incomplete:  some  language 
features  were  left  out  and  sore  restrictions  were  made.  These 
omissions  seem  to  be  due  to  complexity  and  point  to  parts  of  the 
language  worth  considering.  The  omissions  include:  real 
arithmetic,  GO  TOs,  ALPHA-type  The  following  features  are 
imperfectly  described:  classes,  procedures  and  functions  with 
regard  to  global  variables.  This  document  does  not  replace  the 
original  definina  report,  it  only  supplements  it. 


H0ARB74  1*19 

Hoare,  C.A.P.;  'Monitors:  an  Opera-  ing  System  Structuring  Concepts; 
Communications  of  the  ACM,  vol.17.  no. 10,  (October  1974),  pp,54P- 

557. 

This  paper  presents  a  very  good  d<:Scription  cf  how  monitors  may  be 
defined  and  applied  to  a  number  oi'  practical  problems  in  operating 
systems.  Varioiis  details  are  discussed,  such  as  the  peculiar 
nature  of  the  "condition  variabl(>,"  proof  rules  which  may  be 
stated  for  monitors,  and  how  a  monitor  may  be  implemented  using 
semaphores.  (This  las-^  is  rather  confusing,  since  not  all  the 
semaphore  opera-^ions  are  stated  explicitly)  . 

The  most  valuable  aspect  of  ^:he  paper  is  the  extensive  set  of 
examples,  which  both  elucidate  the  properties  of  monitors,  and 
give  a  good  idf=a  of  the  wide  variety  cf  problems  to  which  they 
might  be  applied. 


HOLT73a 
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Holt,  R.C,;  Teaching  the  Fatal  Disease  (or)  Introductory  Computer 
Programming  Usinn  PL/T ;  SIGPLAN  Notices,  vol.R,  no, 5  (May  1973) 
pp. B- 23. 

The  author  makes  plentiful  use  of  humour  and  examples  to  support 
his  dual  claim  that  PL/I  is  a  good  language  to  use  in  teaching 
introductory  programming  (or  implementing  computer  systems)  ,  but 
that  successful  use  of  PL/I  depends  upon  restricting  oneself  to  a 
small  subset  of  the  language.  He  claims  that  to  sue: cess f ull y 
teach  (or  use)  structured  programming  techniques,  one  must  write 
programs  in  a  small  language  that  can  be  completely  mastered.  The 
rules  he  suggests  for  subse+-ting  the  language  restrict,  control 
constructs  to  a  structured  set,  and  res-^rict  data  types  to  avoid 
the  messy  conversion  and  precision  rules. 


HOLT73b  11*11 

Holt,  R.C,  and  Wortman,  D.P. ;  Structured  Subsets  of  the  PL/I 
Language;  University  of  Toronto,  Computer  Systems  Research  Group, 
no.  27  (Tictober  1973)  pp.1-27. 

This  papc'r  presents  a  sequence  of  subsets  of  the  PL/I  language 
developed  by  the  authors  for  the  purpose  of  teaching  introductory 
programmirg.  The  subsets  are  oased  on  the  thoughts  given  in 
"Teaching  the  'p’a'^-al  Disease"  ()n  taming  PL/I  for  teaching 
structured  programming.  A  description  of  the  University  of 
Toronto's  SP/k  compiler  which  enforces  use  of  the  subsets  is 
given . 


H0PKINS71  2*8 

Hopkins,  M.  ;  Probl<^ms  of  PL/I  for  Systems  Programming;  SIGPLAN 
Notices,  vol.  6,  no.  U  (1971)  pp  89-91. 

This  is  a  description  by  an  IBM  project  head  of  the  implementation 
of  a  subst.antial  system  in  PL/T.  Aside  from  mentioning  the  many 
deficient  or  inefficient  PL/I  constructs  and  the  difficulty  of 
obtaining  a  qood  compiler,  Hopkin:;  points  out  that  programming  in 
a  high-level  language  often  Irads  to  more  efficient  sys''-ems 
because  of  the  understandable  nature  of  the  source  code.  He  claims 
that  most  modules  are  poorly  imp]emented  the  first  time,  and  that 
experience  gained  is  often  not  pu"*  to  use  because  of  the  natural 
reluctance  to  tamper  with  a  "working"  program.  Not  a  great  paper, 
but  at  two  pages  it's  worth  your  lime. 


H0PKINS72  4*13 

Hopkins,  M.E,;  '^he  GOTO  Controversy:  A  Case  for  the  GOTO;  SIGPLAN 
Notices,  Vol. 7,  No. 11,  (November  1972),  pp. 59-62. 

Because  the  GOTO  Controversy  sterns  totally  dead  (at  least  in  an 
university  environment)  as  a  result  of  overwhelming  opposition  to 


the  consiTuct,  •♦■his  paper  makes  good  reading.  It  points  out  many 
reasons  for  retaining  the  fiOTO  in  modern  programming  languages. 
The  major  emphasis  is  on  the  fac*-  that  programming  without  GOTO's 
does  not  imply  good  ’’structured”  programming,  neither  does  the 
presence  of  the  GOTO  imply  badly  structured  programming,  in  fact, 
many  people  in  trying  to  eliminate  the  construct,  lose  sight  of 
the  ultimate  goals. 


ICHBIAH73  1*11 

Ichhiah,  J.D.,  Pissen,  J.P.,  and  Heliard,  J.C.;  The  Two-Level 
Approach  to  Data  Independent  Programming  in  the  LIS  System 
Implementation  Language;  Proceedings  of  the  IFIP  TC-2  Conference 
on  Machine-Oriented  High-Level  Languages  (1973)  (to  appear). 

This  paper  describes  a  two-le/el  approach  to  defining  data 
structures  which  permits  separatian  of  the  semantic  properties  of 
data  from  their  effective  implementation.  ’’implementation  parts” 
are  provided  for  specification  of  low-level  features  of  a 
structure  when  machine  dependencies  so  reguire.  The  syntactic  and 
semantic  implications  of  this  feature  are  discussed.  The  authors 
conclude  that  LIS  users  enjoy  the  advantages  of  a  high-level 
language  with  typechecking,  an  i  that  transferability  of  LIS 
programs  is  facilitated  by  the  Isolation  of  machine-dependencies 
in  implemt'ntation  parts. 


KERPFLMAN71  CR22,446  1*10 

Kerpelman,  C,  ;  Clarification  of  FORTRAN  Standards  Secor:d  Report; 
Communications  of  the  ACM,  vol.14,  no, 10  (Oct,  1971)  pft,  628-642  . 

A  revision  of  +:ho  first  FORTRAN  standards  report  is  presented 
clarifying  ambiguities,  specifying  definitions  omitted,  correcting 
errors  and  discussing  addition;  and  extensions  to  the  standards 
and  language.  The  article  would  ue  of  major  interest  only  ^o 
specie  lis  c.s  as  it  is  ext  remely  detailed  and  low  level;  however  it 
serves  as  a  good  example  of  standardization  and  documentation 
problems  that  occur  in  any  attemp*  at  precise  language  de^finition. 
Well  writ*en  and  easily  understo  )d  because  of  its  nature  and 
forma  t. 


KJFLDAAS69  CR22,795  1*2 

Kjeldaas,  P.M.;  Security  in  Softw.ire;  TAG  Journal,  vol.  2,  no.  2 
(196D)  pp. 25-36. 


KNnTH71a  9*14 

Knuth,  D.E.,  and  Floyd,  P, F  ;  Notes  on  Avoiding  ”go  to” 
Statements;  Information  Processing  Letters,  vol. 1 ,  no.1  (Feb. 
1971)  pp. 23-31. 
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This  paper  discusses  the  use  of  the  "goto*’  statemert  and  methods 
of  avoiding  them.  The  ’’goto"  statement  can  be  replaced  by  a 
procedure  call,  or  a  program  segment  containing  a  "goto"  can  be 
imitated  by  using  an  iterative  loop.  The  methods  are  applied  to 
two  typical  programming  examples:  symbol  table  searching  and 
backtracking.  The  article  discusses  when  certain  methods  are 
desirable  and  when  they  would  only  add  ambiguity  to  the  program. 


KNUTHTIb  CR.:2,300  9*12 

Knuth,  D.E. ;  An  Empirical  Stud’'  of  FORTRAN  Programs;  Software  - 
Practice  and  Experience,  vol.  1,  no.  2  (April/June  1971)  pd.105- 

1  33. 

This  paper  deals  with  a  study  on  a  sample  of  programs  written  in 
FORTRAN  by  a  wide  variety  of  ])eople  for  a  wide  variety  of 
applications.  Statistical  results  of  the  study  are  presented  in 
the  paper,  together  with  some  of  '<:heir  apparent  implications  for 
future  work  in  compiler  design,  The  principal  conclusion  which 
may  be  drawn  is  the  importance  of  a  table  of  frequency  counts 
which  record  how  oOten  each  statement  is  performed  in  a  typical 
run.  With  the  table  of  frequency  counts,  a  programmer  or  an 
optimizing  compiler  may  optimise  a  program  by  merely  optimizing 
those  portions  of  the  program  which  are  executed  most  frequently, 
and  thus  reduce  the  amount  of  i;irae  spent  in  producing  efficient 
prog  rams . 


KNUTH73a  2*14 

Knuth,  D.E.;  A  Review  of  S_.ruc^red  Programming;  Stanford 
University,  Department  of  Computer  Science,  Technical  Report  STAN- 
CS-73-371  (June  1973)  . 

This  report  contains  a  detaila^d  review  of  the  book  Structured 
Programming  in  the  form  of  letters  to  each  of  the  three  authors 
(Dahl,  Dijkstra,  and  Hoare) .  Each  letter  is  opened  with  very 
flattering  compliments  to  the  autlior,  and  then  discusses,  in  a 
point  by  point  fashion,  many  (s^ometimes  minute)  details  of  that 
author's  chapter  in  the  book. 

Knuth's  points  are  too  numerous  to  list.  They  are  often 
controversial,  inspiring  one  to  reread  portions  of  the  book  to 
refresh  his  memory  and  "take  sides."  Especially  interesting  is 
Knuth's  application  of  Simula  classes  (frcm  Dahl's  chapter)  to  a 
problem  which  Di-jkstra  solves  in  liis  chapter. 


KNUTH73b  CR2b,533  1*17 

Knuth,  D.  E.  ;  The  Art  of  Compjiter  Programming  -  V3/Sorting  and 
Searching  Addison-Wesley ,  (1973),  pp.722. 

This  book  is  an  excellent  survey  of  sorting  techniques  (chapter  5) 
and  searching  techniques  (chapter  6).  The  author  covers  elementary 
techniques  of  internal  sorting  as  well  as  various  "optimum" 
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sorting  techniquf^s.  He  covers  many  tape  sorting  techniques,  with 
a  brief  word  on  disk  sorting.  In  the  chapter  on  searching,  he 
covers  several  tree  representation  techniques,  including  Fredkin*s 
TPTE,  as  well  as  several  hash  coding  techniques,  some  of  which 
prove  useful  for  retrieval  on  secondary  keys,  a  topic  of  current 
interest  when  associated  with  "data  base”  analysis.  Knuth's 
presentation  seems  weakened  a  lit  tie  by  his  reliance  on  MIX ,  an 
assembler  language  of  his  own  derivation  for  an  imaginary  machine. 


KNnTH74  1*18 

Knuth,  D.F. ;  Structured  Programming  with  go  to  Statements; 
Computing  Surveys,  vol.6,  no. 4,  (■)ecember  1974),  pp,  261-301  . 

An  important  and  controversial  pa 3er.  No  matter  what  one’s 

opinion  of  this  paper  is,  one  wil I  have  had  to  have  read  it  if  one 
wishes  to  discuss  structured  programming.  It  has  a  nice 
bibliography  as  well. 


KOSINSKI73  1*12 

Kosinski,  P.P.;  A  Data  Flow  Programming  Language;  IBM  RC  4264, 
(March  1  973),  pp.  1-134, 

A  two  dimensional  Data-flow  lanqu  ige  devised  by  the  author  is 
described.  This  language  has  the  property  of  having  no  variables, 
and  no  cotitrol  flow  primitives.  A.lthough  the  language  is  not  very 
useful,  the  ideas  involved  are  interesting. 


LANG69  CR 1  265  2* 1 2 

Lang,  C,T\.;  SAL  -  Systems  Asse  nbly  Language;  Proceedings  of  the 
SJCC,  vol.  34  (196Q)  pp. 543-555. 


LANG70  2*11 

Lang,  C.A.,;  Languages  for  Wri  :ing  System  Programs;  In  Buxton, 
J.N,,  and  Randell,  3.  (ed) ;  Software  Fngineering  Techniques;  NATO 
Scientific  A.ffairs  Division,  Brussels,  Belgium  (1970)  pp.  101-106. 

The  authC'T  weighs  the  advantage's  and  disadvantages  of  assembler 
language  versus  higher  level  Languages  for  writing  system 
programs,  using  criteria  such  as  efficiency,  amount  ctf  control 
over  the  n.achine,  und^rstandabili  :y,  and  machine  independence.  He 
suggests  areas  •'■o  look  at  when  designing  a  system  program 
language . 

LEAVENWOR'T  H7  2  CR2u,  148  2*1  5 

Leavenwor+h,  3.M.;  Programming  W  uth  (out)  the  GOTO;  Proceedings  of 
the  ACM  1^72  Annual  Conference  (1972)  pp. 782-786. 


Thp  author  presents  a  brief  history  of  the  GOTO  controvprsy.  The 
GOTO  does  not  appear  in  formal  systems  such  as  the  Post  system  or 
Kleene  general  recursive  functions,  but  has  been  added  to 
programming  languages.  The  existence  of  the  GOTO  as  a  primitive 
opera‘’’ion  on  machines  has  influenced  the  design  of  high  lev^l 
languages.  The  author  summarizes  both  sid^s  of  the  argument.  In 
its  favor,  the  GOTO  is  needed  for  abnormal  exits  from  blocks  or 
procedures,  efficient,  useful  for  synthesis  purposes.  However, 
programs  without:  GOTOs  are  more  easily  understood,  debugged,  and 
modified.  It  is  easier  to  prove  assertions  about  programs  which 
contain  no  GOTOs.  Finally,  -t-he  GOTO  is  frequently  misused  to 
synthesize  more  sophisticated  control  structures. 


LTSKOV73  3*13 

Liskov,  B.  ;  Peport  of  Session  on  Structured  Programming;  SIGPLA.N 
Notices,  vol.B,  no. 9  (September  1^73)  pp.5-10. 

An  overview  of  the  definition  of  structured  programming  is  given, 
including  levels  of  abstraction,  abstract  data,  etc.  The 
discussion  includes  sections  on  monitors,  protection,  and 
construction  of  structured  programs  as  well  as  linguistic  features 
which  should  be  provided  by  a  structured  programming  language. 


LTSK0V74  1*14 

Liskov,  P.H.,  and  Zilles,  S.;  Programming  with  Abstract  Da-^a 
Types;  Proceedings  of  the  Symposium  on  Very  High  Level  Languages, 
SIGPLAN  Notices,  Vol,*^,  No. 4,  (April  1974),  pp.  50-59  . 

This  paper  describes  an  approach  to  programming  based  on  data 
types  and  functional  abstraction.  The  approach  evolved  from  work 
on  designing  a  language  for  structured  programming,  and  language 
f'^'atures  supporting  the  use  of  abstraction  for  structured 
programming  are  discussed.  These  features  include  modular 
compilation,  permitting  the  programmer  to  abstract  upon  other 
abstractions;  wo  forms  of  modules:  procedures,  to  support 
functional  abstraction,  and  operation  clusters  (which  define  a 
data  type  and  all  allowable  operations  on  that  type) ,  to  support 
data  type  abstraction;  restricted  access  to  these  modules  through 
cluster  names  and  procedure  names  only;  ex-^ensive  type  checkinq; 
and  only  structured  control  constructs  (no  goto). 

These  features  are  illustrated  using  programming  examples.  The 
syntax  seems  slightly  awkward,  but  th<=  authors  assert  that  the 
awkwardness  enhances  underst andability .  The  paper's  relationship 
to  previous  work  is  reviewed,  and  implementation  considerations 
are  discussed. 


LOCK65  C?10,477 

Lock,  K.;  Struc+urina  Programs  for  Multi-Program  Time-Sharing  On- 
Line  Applications;  Proceedings  of  the  FJCC,  vol.27,  part  1  (1965) 
pp. 45*7-472. 
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The  paper  introduces  the  idea  of  incremental  compilation,  a  scheme 
of  structuring  users*  ALGOL  programs  in  accordance  with  the 
syntactical  unit  of  a  ’’statement"  which  enables  the  user  to  make 
modifications  to  his  source  language  program  at  the  statement 
level  without  recompiling  the  complete  program. 


LYLE^ 1 

Lyle,  D.^’.  ;  A  Hierarchy  of  High  Order  Languages  for  Sys+ems 
Programming;  SIGPLAN  Notices,  vol.  6,  no.  9  (1971)  pp. 73-78. 


MANACHEH7 1 

Manacher,  G.K.;  Some  Design  Principles  for  High  Level  Systems 
Programming  Languages;  University  of  Chicago,  Institute  for 
Computer  Research,  ICR  Quarterly  Report  No. 25  (May  1,  1971)  pp.1- 
17. 

The  attributes  of  high-level  languages  (e.g.,  PL/I,  CPL)  and  those 
of  low- level  languages  (BCPL,  L6,  PL360)  are  listed.  A 
combination  of  these  two  lists  is  taken  as  the  design  strategy  for 
ESPL  a  language  with  high-level  convenience  (phrase  structure 
syntax,  block  structure,  extensibility,  protection,  and  control) 
and  low-level  features  (machine-dependent  data  specification, 
register  access,  system-gualit y  code  emitted).  The  criteria  are 
vague  and  the  discussion  on  how  much  of  any  feature  is  desirable 
is  not  exhaustive. 


MARC0TTY7a  CR27,168  1*16 

Marcotty,  M.,  Schultz,  H.;  The  Systems  Programming  Language  MALUS; 
Software  Practice  and  Experience  4,1,  (Jan. -March  1974),  pp. 79-90. 

MALUS,  a  dialect  of  PL/I  and  an  outgrowth  ot  XFL  is  described. 

It  is  a  compiler  which  can  compile  itself,  and  has  been  used  at 
CDC  to  implement  a  m  ul-^  i- console  time  sharing  system  (MCTS)  on  the 
STAR- 100  and  STAF-65  computers.  Their  success,  as  described  und<^r 
"evaluation,"  may  well  spell  th<=  doom  of  assembly  languages  for 
the  implementation  of  operating  systems,  for  the  instruction  s^t 
for  the  STAR  computer  is  very  complicated  indeed,  yet  the  authors 
did  not  feel  restricted  by  their  use  of  a  high-level  language  to 
implement  a  timesharing  operating  system. 


MARTIN74  1*15 

Martin,  J.J.;  Generalized  Structured  Programming;  AFIPS  Conference 
Proceedings,  Vol. 43,  (1974),  pp. 665-669. 

This  paper  is  of  interest  to  all  who  have  read  any  of  Dijkstra’s 
papers  on  structured  programming.  Martin  is  suggesting  that 
currently  accepted  structured  programming  constructs  be 
generalized.  It  is  the  author’s  claim  that  Dijkstra's  constructs 
are  too  restrictive,  and  actually  lower  program  understandab ilit y 
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throuqh  the  necessity  of  programminq  steps  "that  are  mot  i  vai-ed 
solely  by  structural  restrictions  imposed  by  rules  of  style."  Th^^ 
au-t-hor  cites  particularly  that  Dijkstra's  constructs  require  undue 
program  complexity  to  compute  complex  conditions,  since  the  use  of 
condition  flags  is  often  required. 

To  correct  this  handicap  Martin  proposes  a  n'^'w  set  of  constructs 
which  form  a  superset  of  Dijkstra’s.  The  claim  is  made  that  the 
main  advartaqe  of  structured  programming,  program  decomposabi lit y , 
is  not  lost  with  this  expanded  construct  set.  To  make  these  new 
constructs  clearer,  actual  language  syntax  of  new  statement  types 
that  emulate  thf^  theoretical  constructs  is  presented. 


MAYNOlDD'^.?  CP2  3,ri45  I'S'S 

Maynard,  J.  ;  IJodular  Programming;  Rutterworths,  London  (  1972) 

p  p  .  1  -  1 0  0  . 

The  observations  of  a  professional  programmer  on  the  methods  of 
modular  programming  and  its  benefits  in  cost,  management  control, 
flexibility,  and  program  maintenance.  The  traditional  "monolithic" 
program  is  criticized  for  its  inherent  fragility  after  debuggino, 
the  duplication  of  effort  involved,  and  the  mismatch  of  programmer 
talent  to  problem  that  usually  occurs.  A  step-by-step  design, 
decomposition,  and  implementation  of  a  commercial  problem,  is 
given  with  reference  to  FORTRAN,  COBOL,  PL/I,  /360  assembler,  and 
to  interface  methods.  The  form  of  a  module  library  for  a  software 
procedure  is  discussed. 


MCCPACKEN72  CP2a,910  12*12 

McCracken,  D.D.,  and  Weinberg,  O.M.;  How  to  Write  a  Readable 
FORTRAN  Program;  Datamation,  vol.lB,  no. 10  (October  1972)  pp.73- 
77. 

For  ease  of  documentation  and  for  readability,  programmers  should 
observe  the  described  rules  concerning  comments,  "goto"s,  do- 
Icops,  complicated  expressions,  statement  numbers  and  variable 
name  s. 


MCFARLAND70 


CR2  1 , 223 


McFarland,  C.;  A  Language-oriented  Computer  Design;  Proceedings  of 
the  FJCC,  vol.37  (1970)  pp. 629-640. 


Difficulties  in  using  computers  are  often  the  result  of  poor 
system  design  or  a  mismatch  between  the  language  and  the  computer 
being  used.  It  is  the  responsibility  of  the  user  to  produce  a  good 
algorithm  for  solving  his  problems,  but  he  is  entitled  to  assume 
that  good  cons-^ruct  ion  in  a  higher  level  language  will  produce 
efficient  object  programs.  To  achieve  this  it  is  proposed  that 
hardware,  opi^rating  systems,  and  primary  languages  all  be  designed 
together.  The  article  gives  an  example  of  a  language  (TPL)  and  a 
computer  system  (Hydra)  designed  in  this  manner. 
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MCKFFMAN56  CPl3,47fi  3*11 

McKeeman,  W.'l;  An  .Approach  to  Corapiitor  Lanquage  Design;  Stanford 
University,  Department  of  Computer  Science,  Technical  Report  CS48 
(August  1966)  pp. 1-124. 

The  major  responsibility  of  language  design  should  rest  with  the 
user.  In  order  •*■0  reduce  the  compiler  writing  task  to  one  a  user 
might  undertake,  implement  an  ext end able  compiler  for  a  kernel 
language  which  contains  the  concepts  common  to  all  computing 
tasks . 


MCKEFMANe?  CR14,136  8^11 

McKeeman,  W.M.;  Language  Directed  Computer  Design;  Proceedings  of 
the  FJCC,  vol.31  (1967)  pp. 413-417. 

.An  entertaining  article  which  begins  by  imagining  what  would 
happen  if  we  had  to  compile  on  a  computer  modelled  after  a  Turing 
machine  rather  than  on  one  modelled  after  a  desk  calculator.  The 
author  complains  that  compilers  and  operating  systems  are  getting 
less  reliable  and  more  expensive  to  produce.  Among  the  remedies 
suggested  are:  1.  Making  hardware  designers  write  a  compiler  2. 
Not  designing  machines  with  multiple  arithmetic  formats  and  the 
attendent  conversion  problems  3.  Replacing  the  ability  to  address 
any  word  in  the  machine  with  lexic-level  addressing  4.  Building 
common  needs  (e.g.,  a  scanner)  into  the  hardware. 

’’The  obvious  attack  for  programmers  and  hardware  people  together 
is  to  devise  a  language  which  reflects  what  we  want  to  do  and  how 
to  do  it  (for  instance,  in  parallel)  and  machine  structures 
effective  in  handling  that  language.” 


MCKFFHAN70  CR21,021  12*10 

McKeeman,  W.M.,  Horning,  J.J.,  and  Wortman,  D.B.;  A  Compiler 
5.§Il§Htor;  Prentice-Hall,  N.J.  (1970)  pp.  1-527. 

This  bock  teaches  the  theory  and  practice  of  compiler 
construction.  A  System/360  realization  of  the  tools  is  pres‘=‘nted 
and  documented.  The  theory  section  gives  examples  of  translating 
expressions,  declarations,  and  control  structures,  emphasizing  the 
relationships  between  recognizing  and  attaching  meaning  to  program 
parts.  Theoretical  groundwork  is  laid  for  studying  formal 
solutions  to  the  recognition  process  (parsing).  This  leads  into 
the  discussion  of  automatically  genera-’-ing  parsers  using 
precedence  and  LR  (K)  techniques. 

The  practice  section  describes  both  the  language  XF L  and  the 
components  of  the  translator  writing  system.  The  components  XCOM 
(the  XPL  compiler),  ANALYZER  (the  parser  generator),  and  SKELETON 
(the  proto-compiler)  are  discussed  both  as  tools  for  building 
compilers  and  examples  of  concepts  described  in  the  th'==ory 
section.  Finally,  the  interface  to  OS/360  is  described  in  the 
a  ppendices . 
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MCKEEMAN72 


2*15 


McKeeman,  W.M,; 
Conference  (1972) 


Compiler  Structure; 
pp, 448-455. 


First 


USA-Japan  Computer 


MCKEEMAN74 


2*17 


McKeeman,  W.M.;  Programming  Language  Design:  Advanced  Cour 
Compiler  Construction,  Lecture  notes,  (March  1974),  Chap.  5. 

McKeeman  describes  the  levels  in  what  he  calls  the  problem  so 
tower,  and  points  out  that  the  language  designer’s  task  i 
facilitate  the  programming  process,  which  takes  place  at  a 
the  levels  of  abstraction  of  the  problem  solving  tower.  The 
issues  are  what  structures  are  useful  at  each  of  the  va 
levels  of  abstrac+-ion,  and  ’’the  new  viewpoint  is  that  it  is 
necessary  to  mix  all  the  levels  into  one  notation.  Or,  to  p 
differently,  it  was  a  mistake  to  assume  we  could  think  effect 
in  a  (single)  programming  language,” 
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Several  design  principles  and  desirable  propertic 
simplicity,  use  of  es-*-.a  bl  is  hed  constructs, 
orthogonality,  adequacy,  tr anslat abilit y ,  and  the 
mirror  human  thought  patterns,  A  list  of  important  f 
language  not  necessary  (er  even  advisable)  to  ha 
level,  include:  assertions,  hierarchical  deccmposit 
decomposition,  data  structuring,  abstraction,  seq 
manipulation,  and  redundancy.  The  Algol  languages, 
and  street  languages  are  models  used  for  the 
illustration  of  the  above  features. 

In  this  paper,  McKeeman  has  provided  an  insightful  d 
the  problem  solving  process,  and  as  such  it  is  well 
read  by  software  engineers  as  well  as  programm 
designers . 
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MTLLS69 


5*14 


Mills,  H,  ;  'T’he  Case  A.gainst  GOTO  Statements  in  PL/I; 
no.C224H2  (April  1969) . 


IBM  Report, 


MILLS7 1b 


9*16 


Mills,  H.;  Top  Down  Programming  in  Large  Systems;  in  Fustin, 
P.(ed.);  Debugging  Techniques  in  Larqe  Systems,  Prent ice- Hall , 
Inc.  (1971)  pp. 41-55. 


Top 

f  unct 

state 

princ 

step 

simpl 


down  programming  is  concerned 
ional  specifications  to  simpler  and 
ments  of  the  programming  language 
iples  are  involved  -  1)  verification 
and  2)  utilization  of  only  a  few 
e  sequencing,  IF  THEN  ELSE,  and  DO  W 


with  the  "expansion  of 
simpler  functions,  until 
itself  are  reached. ”  Two 
of  correctness  at  each 
basic  control  structures: 
HILE. 
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The  ideas  presented  can  be  used  to  create  a  structured  program 
from  design  specifications,  or  given  a  large  system,  reorganize  it 
into  a  set  of  more  readable  segments.  The  resultant  programs  can 
be  read  sequentially  in  small  segments,  each  segment  from  top  to 
bottom,  with  all  control  paths  visible,  because  of  GO  TO  free  code 
and  library  and  macro  facilities. 


MILLS72  16=<'17 

Mills,  H.D.  ;  Mathematical  Foundations  For  Structured  Programming; 
IBM  Federal  Systems  Division  7BFSC  72-6012,  (February  1972),  pp. 1- 
62. 


The  author  attempts  to  provide  mathematical  assurance  that  a 
technical  standard  for  structured  programming  techniques  is  sound 
and  practical.  He  observes  a  psychological  side-effect  of  using 
structured  programming:  the  programmer,  having  greater  assurance 
that  his  program  will  be  correct,  is  motivated  to  a  new  level  of 
concentration,  which  in  turn  reduces  errors  even  more.  He 
describes  programs  in  the  form  of  control  graphs,  and  proves  a 
’’structure  theorem":  Any  proper  program  is  equivalent  to  a  program 
whose  formula  contains  at  most  the  BLOCK,  IF-THEN- ELSF ,  and  DO- 
UNTIL,  and  additional  functions  TRUE,  FALSE,  POP,  and  predicate 
function  TOP." 

The  advantages  of  program  structure  in  program  correctness  proofs 
are  shown,  and  the  production  of  these  programs  by  topdown 
expansion  is  discussed. 


MILLS 7  la 

Mills,  H.;  The  Complexity  of  Programs;  in  Hetzel,  W.C.  (ed.)  ; 
P£2:3L§!!L  ;  Prentice-Hall,  Englewood  Cliffs  (  1973) 
pp. 225-238. 

Mills  begins  by  pointing  out  that,  "in  computer  programming,  we 
have  not  yet  discovered  that  complexity  has  weight."  He  gees  on  to 
discuss  the  role  of  structured  programming,  the  complexity  of 
understanding  programs  and  proving  pregrams  correct.  He  defines 
two  types  of  programs:  rational  and  natural,  which  refer  to  the 
knowledge  available  about  the  intprnal  mechanism  of  the  program.  A 
rational  program  is  one  whose  internal  mechanism  is  transparent  to 
some  people;  a  natural  program  is  one  whose  internal  mechanism  is 
known  to  no  one.  Programs  begin  in  the  rational  state  and 
eventually  pass  on  to  the  natural  state  where  they  soon  become 
obsolete.  His  objective  in  measuring  and  controlling  complexity 
is  to  keep  a  program  rational  for  as  long  as  possible,  and 
certainly  much  long«=^r  than  at  present,  before  the  inevitable  rot 
sets  in. 
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MILLS73b  3*16 

Mills,  H.D,  ;  Or.  the  Development  of  Large  Peliable  Programs;  lEFE 
Symposium  on  Computer  Software  Reliability,  New  York  (April  1973) 
pp. 1S5- 159 . 

In  this  paper  Mills  describes  operational  procedures  intended  for 
the  development  of  la rg®  reliable  programs.  These  procedures  are 
based  on  top  down  structured  programming  to  provide  small 
structur^^^d  program  segments  which  facilitate  reading  of  program 
text  and  testing.  With  respect  to  overall  program  correctness,  the 
approach  taken  is  that  rather  than  have  to  claim  that  the  last 
error  has  been  found  (if  that  is  possible)  one  should  strive  to 
never  find  the  first  error.  Mills  feels  this  can  be  accomplished 
by  restructuring  programming  from  a  private  art  into  a  public 
practice  by  having  programs  read  by  others.  Finally,  the  paper 
introduces  •'■he  concept  of  program  development  accounting  as  a 
means  to  record  the  process  of  program  development  and  inspection, 
and  to  provide  proof  of  the  successfulness  of  the  concept  of  never 
finding  a  firs-'-  error  in  the  program. 


MORRTS73a  1*13 

Morris,  J.H.;  Types  are  not  Sets;  ACM  Symposium  on  the  Principles 
of  Programming  Languages  (Oct.  1973)  pp. 120-124, 

The  au-'-hor  argues  that  objects  of  a  type  should  be  should  be 
managed  (i.e.,  created  and  operated  on)  by  the  owner  of  that 
object.  He  proposes  a  module  block,  which  can  selectively  provide 
local  symbols  -^.o  its  users,  including  the  names  of  types.  A 

module  has  sole  write  access  to  values  of  its  local  types,  but  may 

give  out  read  access  •'-o  such  values  if  it  chooses.  Proof  rules 

are  discussed  for  verifying  correct  use  of  modules.  Finally,  the 

author  relates  Simula  classes  and  polymorphic  functions  to  his 
modules. 


MORPIS73b  2*11 

Morris,  J.H,;  Protection  in  Programming  Languages;  Communications 
of  the  ACM,  vol.16,  no.1  (January  19*73)  pp.  15-22. 

Morris  discusses  a  series  of  methods  of  protection  from  hostile 
programs.  It  is  noted  that  a  hostile  program  can  be  either  from  a 
compe-'-ing  business  or  agency,  or  it  can  just  as  easily  be  your  own 
program  which  contains  bugs.  Included  in  the  list  of  devices  are 
discussions  abotit  procedures  as  objects,  local  objects,  type 
protection,  memory  protection,  seals,  and  trademarks.  For  memory 
protection,  one  may  make  reference  to  •'•he  object  local  to  a 
procedure  F,  In  order  to  provide  outside  access,  the  programmer 
can  provide  reference  to  procedures  within  P.  Seals  are  a  method 
of  ensuring  that  a  programmer  has  taken  the  correct  steps  prior  to 
accessing  a  function,  and  aids  in  localization  of  accesses. 
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HOPRIS73C 

Morris,  J.B. ;  Proqramming  by  Semantic  Refinement;  SIGPLAN  Not 
vol.B,  no. 9  (September  1973)  pp.  1  20-122. 

Programmers  are  incapable  of  efficiently 
programs  when  they  are  initially  confronted  wi 
final  program.  Semantic  refinement  is  off 
approach  from  an  abstract  design  to  a  final  i 
is  achieved  by  coding  and  debugging  the  system 
precise  languages,  the  last  of  which  is  a  sys 
language . 

NASSI'73 

Nassi,  I.,  and  Schn eiderman ,  B;  Flowchart  Techniques 
Structured  Programming;  SIGPLAN  Notices,  vol.8,  no. 8  (Aug. 
pp. 1 2-27 . 

With  the  acceptance  of  structured,  top-down,  gotoless  program 
a  computational  model  is  needed  which  prevents  unrestr 
transfers  of  control  and  reflects  the  control  structure  o 
languages  suitable  for  structured  programming.  Some  advantag 
the  flowcharting  language  presented  are  that  the  scop 
iterations  and  IF-'^HFN-ELSE  clauses  are  well  defined  and  vis 
that  ^.h‘=»  scope  of  variables  is  obvious,  and  that  arbi 
transfers  of  control  are  impossible. 
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NAUR63a 


Naur,  P.  ; 
Style;  RT"', 


Algol  Programming:  Go  to  Sta-^ements  and  Good 
vol.3,  no.  3  (1^63)  pp. 204-205. 


NAUR 6 3b 


CR4, 540 


Naur,  P. ;  Revised  Report  on  the  Algorithmic  Language  ALG 
Communications  of  the  A.C.M.  6,  (1963),  pp.1-17. 

"The  report  gives  a  complete  defining  description  of 
international  algorithmic  language  ALGOL  60.  This  is  a  Ian 
suitable  for  expressing  a  large  class  of  numerical  processes 
form  sufficiently  concise  for  direct  automatic  translation 
the  language  of  programmed  automatic  computers”  (from  the 
paragraph) . 

This  is  a  classic  paper  of  computer  science.  It  introduce 
language  that  is  the  father  of  almost  all  later  languages, 
does  so  concisely  and  clearly.  ”Of  particular  interest  ar 
introduction  of  all  the  main  program  structuring  constructs, 
simplicity  and  clarity  of  its  description,  rarely  equalie 
never  surpassed”f Hoare73 ] . 
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NAUR69a  CR19,420  3*12 

Naur,  P.;  Programming  by  Action  Clusters;  BIT,  vol.  9,  no.  3 
(1969)  pp.  250-25P. 


NAUR72  CR25,213  1*12 

Naur,  P.;  An  Experiment  in  Program  Development;  BIT  12,3,  (1972), 

pp. 347-366. 

This  paper  contains  a  detailed,  step  by  step  account  of  the 
considerations  leading  to  a  program  for  solving  the  ''8-queens 
Problem."  Tn  the  author's  opinion  at  least  some  program 
development  does  no+,  and  can  hardly  be  made  to,  proceed  as  a  top- 
down  process  as  advocated  by  Dijkstra  and  Wirth.  Rather,  a 
problem  solving  type  of  process  is  taking  place  in  solving  such 
problems.  In  this  process  high  level  program  descriptions  appear, 
but  only  after  important  details  have  been  explored  at  a  lower 
level . 


NEUMANN69  CR19,622 

Neumann,  P.G.;  The  Pole  of  Motherhood  on  the  Pop  Art  of  Systems 
Programming;  Proceedings  Second  ACM  Symposium  on  Operating  Systems 
Principles  (Oct.  1969)  pp. 13-18. 

The  author  seeks  to  identify  the  reasons  why,  in  spite  of  what 
Mother  has  told  us,  we  continue  to  pay  no  more  than  lip-service  to 
the  principles  of  good  system  design  and  implementation.  Everyone 
agrees  that  clarity  and  efficiency  are  important,  but  nobody  does 
anything  about  realizing  them.  Several  interesting  paragraphs  on 
the  use  of  higher-level  languages  are  included. 


NTEVERGELT70  CR20,659  2*14 

Nievergelt,  J.,  and  Inland,  M.I.;  Bounce- and-S kip :  a  Technique  for 
Directing  the  Flow  of  Control  in  Programs;  The  Computer  Journal, 
vol. 13,  no. 3  (August  1970)  pp. 261-262. 

The  bounce-and-skip  technique  for  directing  the  flow  of  control  in 
block  structured  programs  was  d<=‘veloped  as  a  result  of  the  search 
for  alternatives  to  the  'go  to'  statement  which  was  questioned  by 
Dijkstra  in  1968  as  a  desirable  feature  of  high-level  programming 
languages.  '^his  method  is  regarded  by  the  authors  as  an  efficient 
way  to  implement  all  of  the  common  control  statements  of  high- 
level  languages  as  well  as  a  tool  for  program  debugging. 

Bounce-and-skip  provides  the  user  with  two  options:  To  delay  the 
use  of  the  result  of  a  test  ind-^f inite ly ,  or  to  make  the  entry  and 
exit  of  BEGIN_END  blocks  conditional  upon  the  last  test  performed. 

Each  test  performed  is  coded  as  either  neutral  (its  result  has 
already  been  used),  successful  or  unsuccessful.  This  indicator  is 
matched  to  a  list  of  permissible  settings  of  the  indicator 
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associated  with  each  BEGIN  and  END,  Under  a  mismatch  condition 
control  is  prohibited  from  entering  through  a  given  FEGIN  and  thus 
it  skips  the  block,  or  control  is  not  allowed  to  exit  through  a 
given  END  and  hence  it  bounces  and  positions  itself  just  after  the 
corresponding  BEGIN. 


PETSPSON73  CP26,120  6*13 

Peterson,  W.W.,  Kasami,  T. ,  Tokura,  N.;  On  the  Capabilities  of 
While,  Repeat,  and  Exit  Statements;  Communications  of  the  ACM, 
vol.16,  no. 8  (August  1873)  pp, 803-512. 

Using  a  flowchart  formalism  similar  to  [Ashcroft  71],  this  paper 
also  describes  a  GOTO  removing  transformation  for  programs  using 
arbitrary  GOTOs.  This  -t-ransformat ion  results  in  a  GOTO-free 
program  which,  in  general,  is  longer  than  the  original,  but  which 
has  the  same  execution  time  as  the  original.  (Roth  length  and 
execution  time  are  incr<=ased  by  the  transformation  of  Ashcroft  and 
Manna).  These  transformed  programs,  however,  make  use  of  th=‘ 
repeat  and  multi-level  exit  primitives  (in  addition  to  if-then- 
else)  .  The  absence  of  this  multi-lev<^l  exit  from  most  current 
programming  languages,  (SUE  and  other  languages  with  this 
primitive  are  not  mentioned),  and  its  positive  or  negative 
contribution  to  the  understandab ilit y  of  programs,  are  not 
d iscu  ssed , 


POOLE68  CR18,612  1*10 

Poole,  P.C.,  and  Waite,  W.M.;  Machine-Independent  Software; 
Proceedings  of  ACM  Second  Symposium  on  Operating  Systems 

Principles  (October  1869)  pp. 19-2h, 

The  authors  advocate  that  machine  independence  be  achievfd  through 
the  use  of  macros  rather  than  compilers,  with  the  following 
principal  ad  van-*-ages :  1.  The  abstract  machine  may  be  flexibly 

extended,  "here*s  no  need  to  design  a  "complete"  language  at  the 
outset.  2.  Optimization  may  be  tailored  to  specific  needs, 
through  modification  of  the  appropriate  macros. 

RICHAPDS69  CR18,25R  4*10 

Richards,  M, ;  PCPL:  A  Tool  for  Compiler  and  System  Writing; 
Proceedings  of  the  SJCC,  vol.34  (1969)  pp. 557566. 

BCPL  is  a  simplification  of  CPL  (Basic  CPL)  developed  as  a  tool 
for  writing  relatively  machine  independent  systems  programs, 
especially  compilers.  The  most  important  characteristic  of  the 

language  is  its  simple  semantic  structure  built  arouni  "an 

idealized  object  machine"  which  makes  BCPL  reasonably  machine 
independent  and  easy  to  define  accurately.  The  language  is 

typeless  (the  only  data  object  being  a  bit  string  of 

implementation-defined  length)  and  has  a  wealth  of  constructs  to 
control  flow  in  an  orderly  fashion.  The  article  gives  an 

interesting  discussion  of  ■♦■he  advantages  of  typeless  languages  and 
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has  some  general  comments  on 
implementation. 


RTCHARDS7 1 

Richards,  M,;  The  Portability 
Practice  and  Experience,  vol.  1, 
1  46. 


ROBERTS67 

Rob<=rts,  K.V.;  The  Rea 
Bulletin,  vol. 10,  no. 4  (m 


ROSS70 

Ross,  n.T.;  Oniform  Re 
Software  Engineering  La 
Academic  Press,  Mew  York, 

Presented  is  a  suggest 
developed  for  the  develop 
lack  of  engineering  in 
methodology,  noting  that 
what  was  asked  for. 

Foss  goes  on  to  sugge 
design  be  adopted.  This 
as  the  ’’top-down”  approac 
the  ideas  that  were  more 
in  STRUCTURED 
notation  that  Ross  sugges 
references  to  his  own 
paper  has  been  superceded 

The  paper,  however,  is  inhere 
view.  On  one  hand  Ross  is  trying 
the  rage  of  Software  Engineers, 
programmers  working  in  high  level 
degree  of  control  over  address 
the  very  principle  that  Hoare  is 
languages  move  away  from  [Hoare73 


SAMMET71 

Sammet,  J.E.;  A  Brief  Survey 
Implementation;  SIGPLAN  Notices, 
19. 

A  good,  concise  survey  which  t 
managerial  and  technical  reasons 
high-level  language;  some  of  th- 
languages;  a  list  of  ’’motherh- 


design  of  languages  for  system 
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programminq  language  characteristics;  brief  and  not-too-usef ul 
descriptions  of:  ALGOL,  BLISS,  FORTRAN,  IMP,  LRLTRAN,  NELIAC, 
Pascal,  and  PL/I.  Recommended,  and  it's  short. 


SCHNEIDERMAN73  2*12 

Schneiderroan ,  B. ,  and  Scheuerman,  P. ;  Structured  Data  Structures; 
State  University  of  New  York  at  Stony  Brock,  Department  of 
Computer  Science,  Technical  Report  no. 16  (June  1973)  pp,1-34. 

The  report  proposes  a  Data  Structure  Description  and  Manipulation 
Language  (DSDML)  which  provides  for  the  creation  of  a  restricted 
class  of  data  structures,  but  ensures  the  correctness  of  the 
program.  This  is  accomplished  by  having  the  user  explicitly 
declare  the  form  of  the  structure  (e.g.,  list,  tree,  ring,  queue, 
stack  and  deque) ,  restrict  the  permissible  operations  on  the 
structure,  and  specify  execution  time  checks  to  ensure  the  form  of 
the  structure  is  not  altered  (e.g,,  by  the  insertion  of  some 
pointer) .  The  authors  claim  that  they  wish  to  eliminate 
unrestricted  branches  or  edges  (i.e,,  pointers)  from  data 
structures  iust  as  the  goto  has  been  eliminated  to  avoid  poorly 
structured  programs.  They  also  claim  that  using  their  system  top- 
down  programming  can  be  achieved  in  terms  of  data  structures  by 
having  the  nodes  of  a  given  level  structure  serve  as  headers  for 
the  structures  at  the  next  level. 


SIME73 


CR25, 309 


1*1  1 


Sime,  M.E,,  Green,  T.R.G.,  and  Guest,  D.J,;  Psycholo 
Evaluation  of  Two  Conditional  Constructs  Used  in  Com 
Languages;  International  Journal  of  Man-Machine  Studies,  v 
no.1  (Jan.  1973)  pp. 105115, 

Although  papers  comparing  structured  and  unstructured  lang 
exist,  very  little  hard  data  has  been  presented.  Most  st 
talk  about  users  with  some  experience.  By  adopting  a 
simplified  language,  and  through  the  use  of  interactive  dev 
the  authors  have  obtained  data  comparing  IF... GO  TO  to  a  nest 
structure  using  non-experienced  users.  The  results  verify 
current  critisism  of  the  GOTO,  but  more  important  an  new  meth 
studying  features  of  languages  is  presented. 
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Strachey,  C. ;  System  Analysis  and  Programming;  Computers  and 
Computation,  S.H.  Freeman  and  Co.,  (1971),  pp, 70-77. 


This  paper  is  intended 
programming.  Although  the 
analysed  and  constructed 
written,  it  has  little 
exper ience . 


to  be  read  by  people  inexperienced  in 
discussion  of  how  a  sample  problem  is 
hierarchically  is  interesting  and  well 
to  offer  people  with  considerable 
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VON  PESCHKE71 

von  Peschlce,  J.  ;  PL/I  Subsets  for  Software  Writing;  SIGPLAN 
Notices,  vol.6,  no, 4  (1P71)  pp. 16-22. 

The  article  discusses  the  possibility  of  extending  a  subset  of  the 
PL/I  language  for  use  in  compiler  and  operating  system  writing. 
The  primary  aims  of  high  level  languages  are  machine  independence 
and  readabil :^t y .  This  is  contrasted  with  the  need  of  the  producers 
of  software?*'  to  have  full  control  over  all  the  features  of  the 
machine.  Therefore  the  solution  of  the  problem  is  not  a  general 
high  level  language,  but  one  that  is  tailored  to  the  given 
computer,  while  at  the  same  time  retaining  some  of  the  good 
features  of  a  high  level  language.  The  author  suggests  a  subset 
of  PL/I  with  some  extensions  which  he  describes  in  the  article, 
which  would  becom^^  a  good  language  for  software  writing. 


WADSW0PTH73  CP26804  1*15 

Wadsworth,  M.D,;  The  Human  Side  of  Data  Processing  Management; 
Prentice-Hall,  (1973),  pp.  1-244, 

The  text  is  intended  for  large  computer  installations  with  a  staff 
of  15  or  more,  however,  the  arguments  are  valid  for  any 
super i or /subordinate  r ela  t ion  ship . 

This  book  has  ten  chapters.  Chapter  one  presents  five  levels  of 
human  needs  (psychological,  security,  social,  esteem,  and  self- 
realization  or  achievement)  and  four  styles  of  leadership 
(authoritarian,  democratic,  laissez-faire,  and  buddy-buddy).  To 
be  effective,  “^he  manager  must  learn  to  use  all  four  styles  of 
leadership.  Chapters  two  through  five  contain  15  case  studies 
illustrating  which  leadership  style  is  best  suited  to  satisfy  an 
id‘=nt  if iable  level  of  human  need  in  order  to  improve  individual 
performance.  The  checklists  to  identify  the  level  of  human  need 
are  excellent.  Chapters  six  through  eight  give  additional 
examples  to  improve  profitability  and  productivity  in  system 
development,  system  maintenance,  and  computer  operations 
respectively.  Chapter  nine  details  ways  to  improve  "user” 
acceptance,  cooperation,  and  involvement.  Chapter  ten  is  directed 
to  the  EDP  manager. 


WAITETOa  CR19,610  5*12 

Waite,  W.M.;  Building  a  Mobile  Programming  System;  The  Computer 
Journal,  vol.13,  no. 1  (February  1970)  pp. 28-31. 

In  this  paper  -t-he  author  discusses  a  technique  which  he  believes 
to  be  fundamental  to  the  improvement  of  mobility  of  programming 
systems.  It  is  recognized  that  the  mobility  of  a  programming 
system  and  the  associated  application  programs  is  an  extremely 
important  aspect  whenever  a  user  upgrades  or  changes  his 
equipment.  The  mobility  of  systems  software  is  a  function  of  the 
number  of  installations  which  are  involved  and  in  general,  the 
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mobility  of  a  program  is  completely  dependent  on  the  mobility  of 
the  programming  system  it  utilizes. 

The  technigue  for  providing  mobility  is  based  on  the  concept  of  an 
§^stract  rnachine:  a  hypothetical  computer  ideal  for  a  particular 
task.  The  program  for  this  task  is  written  for  the  abstract 
machine  and  to  run  such  a  program  on  a  real  machine,  the  abstract 
machine  must  first  be  realized  in  some  way. 

The  author  concludes  the  article  by  discussing  both  the  advantages 
and  disadvantages  of  the  technique  of  abstract  machine  modelling 
and  points  out  that  the  system  has  proved  extremely  mobile  in 
practice,  having  been  implemented  in  less  than  one  man-weak  on 
nine  different  occasions. 


WAITE70b  CP20,135  1*10 

Waite,  W.M.;  The  Mobile  Programming  System:  STAGE2;  Communications 
of  the  ACM,  vol.  13,  no.  (July  19^0)  pp.h15-421. 


WEGBPI’IT71  CR23,S16  2*14 

Wegbreit,  R. ;  The  ECT.  Programming  System;  Proceedings  of  the  FJCC, 
Vol. 39  (1971),  pp. 253-262. 

This  article  describes  a  number  of  ideas  for  facilitating  program 
production  which  are  being  conglomerated  into  a  project  called  the 
ECL  programming  system.  The  goals  of  the  project  are: 

1)  To  allow  problem-oriented  description  of  data  types  and  control 
structures,  and  control  over  a  wide  range  of  application  areas, 

2)  '^o  facilitate  program  construction  and  debugging, 

3)  To  allow,  and  assist  in,  the  development  of  highly  efficient 
programs, 

4)  To  facilitate  smooth  progression  between  initial  program 
construction  and  final  realization  of  an  efficient  product. 

Ideas  being  implemented  to  accomplish  these  goals  include  a 
compatible  interpreter-compiler  scheme;  a  very  extensible  language 
(extensions  allowed  on  syntax,  data  types,  and  control 
structures) ;  systematic  variability  which,  along  with 

boot s ♦-rapping ,  allows  sophisticated  manipulation  of  the  system; 
greater  user  control  over  errors  and  interrupt  handling;  and  an 
interactive  multiprogramming  scheme.  In  general,  the  author 
favors  a  very  flexible  and  powerful  set  of  tools  for  program 
prod  uc  tion . 


WELLS73 


1*12 


Wells,  M.n, ;  Alqorithmic  Languages  and  Machine-Oriented  Tasks; 
Proceedings  of  the  IFIP/TC2  Conference  on  Machine-Oriented  High- 
Level  Languages  (August  1973). 

The  author  summarizes  a  theme  of  the  paper  when  he  states  "This 
author  believes  that  there  is  much  less  that  is  peculiar  o 
systems  programming  than  many  people  believe."  He  argues  that  the 
term  high-level  should  imply  small,  algorithmic,  machine- 
independent  languages.  He  further  claims  that  the  attempt  to 
control  the  implementation  details  is  the  cause  of  implementation 
languages  being  massive  and  complex. 

To  solV’^'  the  technical  difficulties  of  efficient  compilation,  he 
suggests  that  we  study  compiler  and  hardware  design  as  seperatp 
problems.  Moreover,  we  should  restrict  ourselves  to  subsets  of 
algorithmic  languages  for  which  efficient  compilers  can  be 
written. 


WIRTH68  CR14,506 

Wirth,  N.  ;  PL360,  A  Programming  Language  for  the  360  Computers; 

Journal  of  the  ACM,  vol.  15,  no.  1  (January  1968)  pp. 37-74. 


WI 8*^87 la  CP  2  1,6 30  18*1  6 

Wirth,  N. ;  Program  Development  by  Stepwise  Refinement; 
Communications  of  the  ACM,  vol. 14,  no . 4  (April  1971)  pp. 221-227. 

Programming  is  usually  taught  by  examples.  Unfortunately  these  do 
not  usually  demonstrate  widely  applicable  techniques,  rather  they 
show  what  a  computer  can  do.  Wirth  proposes  a  better  method  of 
teaching,  that  of  stepwise  refinement. 

Stepwise  refinement  is  intended  to  demonstrate  the  gradual 
development  of  a  program.  As  an  example,  Wirth  takes  the  eight 
queens  problem  and  applies  the  method.  First  the  problem  is 
stated  in  very  general  terms,  leaving  many  details  unspecified. 
The  problem  is  gradually  refined  by  filling  in  details  at  each 
succeeding  step.  At  each  step  a  choice  is  made  as  to  the  best 
design  and  solution  for  that  level.  This  process  continues  until 
the  solution  is  expressible  in  a  programming  language. 

Wirth  concludes  that  this  method  successfully  splits  the  problem 
into  a  number  of  subtasks  at  each  step.  The  degree  of  modularity 
obtained  determines  the  ease  or  difficulty  of  the  problem.  This 
method  allows  one  to  express  the  problem  in  notation  that  is 
natural  to  the  problem,  until  the  notation  of  the  problem  becomes 
that  of  the  programming  language.  Each  step  requires  concise 
design  decisions  which  affect  the  final  solution. 
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WrPTH71b  CP26,92S  16^11 

Wirth,  N,;  The  Programming  Language  Pascal;  Acta  Informatica  1, 
( 1 975) ,  pp, 35-63. 

This  paper  describes  the  programming  language  Pascal  and  provides 
a  justification  for  its  creation.  Wirth  intended  the  language  as 
a  teaching  vehicle  and  as  a  tool  for  the  creation  of  large 
programs.  He  tried  to  keep  the  language  small,  systematic,  and 
efficient.  Pascal  introduced  several  novel  concepts  and  has 
inspired  several  other  languages  [see  Clark71]. 

In  style,  this  paper  is  like  the  Algol  60  report  but  unfortunately 
it  is  neither  as  clear  nor  as  complete.  See  [Habermann  73]  for 
harsh  but  partially  justified  criticism. 


WIPTH71C  CR23,196  4*11 

Wirth,  N. ;  The  Design  of  a  PASCAL  Compiler;  Software  Practice  and 
Experience,  vol.  1,  no.  4  (October/December  1971)  pp, 309-333. 


WIPTH73  2*12 

Wirth,  N;  Systematic  Programming:  an  Introduction;  Prent ice- Hall , 
Inc.,  Englewood  Cliffs,  N.J.  (1973)  pp. 1-169, 

This  book  introduces  programming  as  the  art  or  technique  of  of 
constructing  algorithms  in  a  systematic  manner,  as  a  discipline  in 
its  own  right.  No  specific  area  of  application  is  emphasized. 
This  book  is  tailored  to  the  needs  of  people  who  view  a  course  on 
systematic  programming  as  a  (possibly  neglected)  part  of  basic 
mathematical  training.  Few  people  beside  Dijkstra  will  fail  to 
profit  from  reading  it. 


WTPTH74 

Wirth,  N.  ;  On  the  Composition  of  Well  Structured  Programs; 
Computing  Surveys,  vol. 6,  no. 4,  (December  1974),  pp.  247-259. 


W00DGER72  CP24,757  3*13 

Woodger,  M. ;  On  Semantic  Levels  in  Programming;  Proceedings  of 
IFIP  Congress  71,  vol,  1  (1972)  pp, 402-407. 

This  paper  discusses  the  recognition  of  levels  of  meaning  in 
relation  to  *he  programming  of  a  solution  to  a  given  problem.  An 
analogy  with  the  ’’operating  manual"  of  a  machine  is  made  in  an 
attempt  to  expose  inadeguacies  in  present  programming  practice. 
The  author  main’-ains  that  at  each  level  an  abstraction  of  a 
process  (whose  meaning  is  clear  without  reference  to  the  other 
levels)  must  be  made.  Finally,  he  argues  that  conventional 
programming  prac+;ices  tend  to  confuse  these  levels,  and  that 
subroutines  do  not  solve  the  problem. 


WORTMAN72 


CR25,416 
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Wortman,  D.B.;  A  Study  of  Language-Directed  Computer  Design; 
University  of  Toronto,  Computer  Systems  Research  Group,  no. 20 
(December  1072)  pp, 1-207, 

Starting  with  a  "clean”  subset  of  PL/I,  the  author  designs  a 
computer  to  implement  its  semantics  directly.  He  then 
analyzes/predicts  its  performance,  and  in  the  process  develops 
tools  which  "could  also  he  used  by  the  programmer  to  evaluate  the 
performance  of  computers."  This  turns  out  to  be  the  major  useful 
part  of  the  work,  because,  as  he  points  out,  "for  languages  with  a 
less  elegant  structure  the  design  problem  is  much  more  difficult." 


WriLF71a  CR23,011  1*10 

Hulf,  W.A,,  Russell,  D.B,,  and  Habermann,  A.N,;  BLISS:  A  Language 
for  Systems  Programming;  Communications  of  the  ACM,  vol.  14,  no. 
12  (December  1971)  pp, 780-790. 

WULF71b  4*12 

Wulf,  W.,  Geschke,  C,,  Wile,  D. ,  and  Apperson,  J.;  Reflections  on 
a  Systems  Programming  Language;  SIGPLAN  Notices,  vol. 6,  no. 9 
(October  1971)  pp, 42-49, 

WULF72a  5*12 


Wulf,  W.A.;  The  GOTO  Controversy:  A  Case  Against  the  GOTO;  SIGPLAN 
Notices,  vol.  7,  no.  11  (November  1972)  pp, 63-69, 


WULF72b  3*10 

Wulf,  W.A.,  Hopkins,  M.E.,  Peterson,  W.W.,  and  Waite,  W.M.  ;  The 
GOTO  Cont rov'='rsy :  Rebuttals  and  Discussion;  SIGPLAN  Notices,  vol. 
7,  no.  11  (November  1972)  pp, 70-91. 


wnLF72c  CR24,717  5*15 

Wulf,  W.A.;  Programming  Without  The  GOTO;  Proceedings  of  IFIP 
Congress  71,  Vol.1,  (1972),  pp, 408-413. 

In  this  article  the  author  explores  the  common  program 
constructions  and  shows  how  they  may  be  realized  without  goto 
statements.  He  then  describes  his  own  experience  with  the 
language  BLISS,  which  is  goto-less.  He  concludes  that: 

(1)  It  does  not  matter  whether  or  not  a  language  includes  the 
goto.  There  are  certain  types  of  control  flow  which  occur  in  real 
programs.  If  these  constructs  are  not  provided  then  gotos  should 
be  used  to  synthesize  them.  The  danger  of  gotos  is  that  the 
programmer  will  do  this  in  obscure  ways. 
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(2)  The  advantage  in  eliminating  the  goto  is  that  these  same 
control  structures  will  appear  in  regular  and  well-defined  ways. 
Both  the  human  and  the  compiler  will  interpret  them  better. 


WULF73 


Wulf ,  W ,  ,  and 
STGPLAN  Notices, 


Shaw ,  M  ,  ; 
vol . 8  ,  n  o,  2 


Global  Variables  Considered  Harmful; 
(Feb,  1973)  pp, 28-34, 


An  extension  of  Dijkstra*s  arguments  against  GOTO’s  to  global 
variables  -  variables  defined  and  modified  over  large  portions  of 
text.  Argues  for  richer  methods  of  defining  variable  scope  than 
the  Algol  block-structured  approach,  F,g,,  one  should  be  able  to 
limit  access  to  stacks  and  pointers  to  push-pop  routines  only_. 

The  authors  argue  that  (a)  keeping  track  cf  global  variables  is 
difficult,  and  (b)  global  variables  complicate  the  process  of 
figuring  out  what  a  program  segment,  whose  actions  depend  on  them, 
does. 


The  authors 
GOTO  problem, 
and  (b) 
Criteria  for 
provided , 


point  out  that  the  problem  is  not  so  simple  as  the 
since  (a)  there  is  no  ’’single  offending  construct,” 
there  are  no  accepted  alternatives  which  avoid  it, 
alternatives  are  presented,  but  no  examples  are 


Y0HE74 


1*1  5 


Yohe,  An  Overview  of  Programming  Practices;  Computing 

Surveys,  vol, 6,  no, 4,  (December  1974),  pp, 221-245, 


According  to 
something  of 
commun icat ion 


the  author,  the  purpose  of  this  paper  is  to  outline 
the  nature  of  "good  programming,"  Since 
between  humans  is  just  as  important  as  communication 
with  the  computer,  the  concept  of  programming  entails  adequate 
documentation  and  certain  other  tasks  to  be  performed.  The  author 
divides  the  programming  process  into  nine  tasks  and  discusses  each 
of  them.  The  paper  is  directed  to  students  or  beginning 
programmers,  but  does  not  exclude  experienced  programmers. 

The  difference  between  coding  and  programming  is  stressed  early  on 
in  the  paper,  when  he  separates  their  two  functions  into  program 
writing  and  design  analysis.  The  author  later  concludes  that 
"coders  are  not  difficult  to  find,  but  a  truly  good  programmer 

is," 


YOUNG S70 


2*12 


Youngs,  F,A, ;  Error-Proneness 
University  of  North  Carolina 
Psychology  (1970)  pp,  1-147, 


In  Programming;  Ph,D,  Thesis, 
at  Chapel  Hill,  Department  of 


This  thesis  basically  describes  a  programming  experiment  to  study 
human  programming  errors  with  an  eye  towards  suggesting 
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Attitudes : 

RrophyCO,  Brown72,  Constant ine6R,  Dijkstra62,  Dijkstra65a, 
Dijkstra72a,  Ershov72,  Garwick61,  Gunderman73,  Horninq74a, 
Miller7U ; 

Structured  proqrammin q : 

Barton70,  Bauer7?,  BGnson73,  ChGathara72a,  Corbin71,  Dahl72, 
Denil73,  Dijkstra65,  Dijkstra68d,  Dijkstra70,  Dijkstra71a, 
Dijkstra71b,  Dijkstra72b,  FloYd72,  Garwick61,  HendGrson72, 
HoltC3a,  Ho3.t73b,  KKernighan74a ,  Kernighan74  b ,  Knuth73, 
Knuth74,  LiskovC2,  Liskov73^  Martin74,  Mills71b,  Mills72, 
Mills73a,  Mills73b,  Horris73c,  Nassi73,  Naur69a,  Naur72, 
Ross70,  Schneiderman73,  Snowdon70,  Snowdon72,  Strachey71a, 
Mirth7la,  Wirth7lb,  Wirth73,  Wirth74,  Woodger72; 

Readability: 


Brophy70 , 
Mills73b, 


Conro w70 , 
Roberts67; 


Kerniqham74b,  McCracken72,  Mills70, 


Human  factors  in  programming: 

Gannon75,  Griffith72,  Horning74a,  Miller74,  Sime73, 
Weinbcrg71,  Youngs70; 


Criteria  for  language  design: 


Bergeron7l,  Bergeron72,  Brinch  Hansen72,  Cheatham72a,  Clark7l, 
Dikstra65a,  Ralkoff70,  Gannon7S,  Hoare69,  Hoare71a,  Hoar972a, 
Hoare72b,  Hoare73a,  Kulsrud74,  Knuth74,  Liskov73,  Manacher71, 
McKeeman66,  McKeeman74,  Morris73a,  Morris73b,  Neeiy73,  Ross70, 
Sammet7i,  Schneiderman73 ,  von  Peschke71,  Wells73,  Hirth71h, 
Wulf71a,  Wulf71b; 


Data  structures: 

Baecker68,  Pal2er67,  Parton70,  Dahl72,  Early74, 
HoarG72b,  Hoare73b,  Ichbiah73,  Knuth73,  Liskov73, 
Morris73a,  Ross70,  Schnei derm an73 ; 

Control  structures: 

Bochman73a,  Princh  Hansen73b,  Conway63,  F.arly74, 
HoarG72b,  Hoare74,  Holt73a,  Knuth73,  Kosinski73, 
Niever gelt70 ,  Peterson73,  Sime73,  Wulf72; 


Hoar e7  2a , 
Liskov74 , 


Fish  er72 , 
Nas  si7  3 , 
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The  GOTO: 


Ashcroft72,  Barton7 
Gries74,  Hopkins'72^  K 
f1ills7lb,  Naur63, 
Wulf72b,  Wulf72c; 

Other  language  features: 

3alzer71a,  Parton70 
Dijkstra65b,  Dijkstr 
Hoare72b,  King71b,  L 
Steeg64; 

Implementation  languages: 

Balzer71a,  Bergero 
Cheatham72a,  Clark7 
Henricksen'72 ,  Hopkin 
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,  Brinch  Hansen72,  Brinch  Hansen73b, 
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1,  Clark73,  Corbato69,  Graham7C, 
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4,  Bichards69,  Sammet71,  von  Peschke71, 
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!•  validation,  and  debu^^ing 


Highly  reccmmended :  Flspas72,  Floyd67a,  Grishman70,  HoarG69, 

Hoare71b,  King71b,  London70c,  Sa tter th wa itG7 2 


ALLFN71  CP22,6H1  4«10 

All^n,  C.D.;  ThG  Application  of  formal  Logic  tc  Programs  and 
Programming;  IBM  Systems  Journal,  vol. 10,  no.1  (Jan.  1971)  pp.2- 
38. 

A  hierarchical  application  of  first-order  predicate  calculus  is  a 
practical  solution  for  proving  the  correctness  of  programs.  Allen 
first  gives  a  brief  introduction  to  formal  logic,  and  then 
develops  the  results  of  Hanna  and  Ashcroft  on  an  elementary  level. 
Finally  he  presents  some  examples  and  theories  of  his  own  as  well 
as  some  applications  of  the  proof  techniques. 


ASHCROFT71  CR21,94n  2*17 

Ashcroft,  E.A.,  and  Manna,  Z.  ;  For ma  1  i-zation  of  Properties  of 
Parallel  Programs;  Machine  Intelligence  6,  Edinburgh  University 
Press,  (1971),  pp.  17-42. 

This  paper  provides  a  very  instructive  introduction  to 
possibilities  for  applying  formal  proof  techniques  to  parallel 
programs.  The  first  section  consists  of  a  definition  of  what  will 
be  considered  a  parallel  program:  it  may  contain  simple 
assignment  statements,  test  statements,  (possibly  recursive) 
process  calls,  and  blocks  defining  parallel  branches.  In  this 
context  the  properties  of  a  "computation,”  and  the  possible  ways 
of  terminating  parallel  segments  are  discussed. 

It  is  shown,  by  example,  how  a  parallel  program  may  be  transformed 
into  a  non-determinist ic  program,  which  is  the  basis  for  the 
desired  formalization.  Also  presented  at  this  stage  are  the 
possible  ways  of  defining  "protected"  sections  of  programs,  which 
are  required  for  the  subsequent  simplification  methods. 

Properties  which  programs  may  have  are  enumerated,  and  the  stages 
in  the  development  of  a  formal  statement  of  the  properties  of  a 
program  are  explained,  using  a  specific  example. 

The  last  major  section  describes  methods  for  program 
simplification,  based  on  the  detection  of  instances  in  which  the 
computation  of  a  program  is  independent  of  the  sequence  of 
execution  of  parallel  segments,  thus  reducing  the  total  number  of 
cases  for  which  formulae  roust  be  derived. 

The  paper  concludes  with  suggestions  of  additional  program 
features  which  might  be  considered  in  similar  fashion. 
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BAECKER6B  CP16,002  1*7 

Baecker,  R.M.;  Fxpe rime n-^ s  in  On-Line  Graphical  Debugging:  The 
Interroga-*- ion  of  Complex  Data  Structures;  Proceedings  of  th^ 
Hawaii  International  Conference  on  Systems  Sciences  (1968)  pp.128- 
129. 

A  study  of  complex  data  structure  interrogation  using  display 
screens  to  help  debug  graphical  language  programs  with  the  focus 
on  keeping  the  level  of  interrogation  suitably  high  to  allow 
sophisticated  sea rch- orie nt ed  questioning  in  keeping  with  the 
level  of  th^  graphical  languages  and  the  data  they  structure.  For 
its  time  the  article  presents  an  advanced  attempt  at  raising  the 
level  of  interactive  debugging  aids  to  a  level  well-suited  to  the 
source  language  used.  It  is  also  one  of  the  first  uses  of  video 
tracing  of  data  to  give  the  interrogator  a  data  history  during  his 
questioning. 


BALZER69  CR18,06F  2*12 

Balzer,  R.!^.;  EXDAHS-Extendable  Debugging  And  Monitoring  System; 
Proceedings  of  the  SJCC,  vol.lU,  (1969),  pp, 567-580. 

Describes  a  debugging  system  which: 

1.  analyzes  a  user’s  program  and  adds  special  debugging 
s tat emen t s  to  it 

2.  generates  a  symbol  table  and  model  of  the  program 

3.  compiles  the  augmented  program 

U.  executes  the  augmented  program,  resulting  in  a  "history  tape" 
being  written,  containing  all  relevant  information  of  the 
processing  (generated  by  the  inserted  debugging  statements). 

This  history  tape  may  now  be  examined  by  invoking  a  set  of 
debugging  routines  via  commands  through  a  CRT  terminal.  The 
retrieved  data  is  formatted  on  the  screen.  It  is  also  possible  to 
monitor  the  execution  of  the  program  (model)  backwards  or 
forwards,  helping  the  programmer  to  pinpoint  the  origin  of 
processing  errors.  '’’he  system  is  extendable  since  all  interfacing 
wi-l-h  the  history  tape  is  done  by  an  information-retriever  routine. 
Therefore  a  programmer  can  add  his  own  commands,  using  the  special 
retrieve  r . 


BERNSTFIN68  CP17,293  4«12 

Bernstein,  W.A.,  and  Owens,  J.;  Debugging  in  a  Time-Sharing 
Environment;  Proceedings  of  the  FJCC,  vol.33  (1968)  pp.7-14. 

This  paper  provides  a  good  examination  of  conventional  debugging 
tools,  and  appraises  their  adequacy  in  view  of  programming 
advances.  It  then  discusses  the  characteristics  of  a  support 
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system  that  meets  the  debugging  and  program  modification  needs  of 
a  time-sharing  system. 


BLAIR 71 


CR23, 016 


4*13 


Blair,  J.;  Extendable  Non-Tnteract ive  Debugging;  in  Pustin, 
R. (ed.),  Bebug^in^  lechni^ues  in  bar^e  Cisterns,  Prentice -Hal 1 
(1971)  pp. 93-115. 


BRADY6H  CR16,000  1*8 

Brady,  P.  ;  Writing  an  Online  Debugging  Program  for  the  Experienced 
User;  Communications  of  the  ACM,  vol.11,  no. 6  (1968)  pp. 423-427. 


BRINCH  HANSEN73a  2*14 

Brinch  Hansen,  P.;  Testing  a  Multiprogramming  System;  Software 
Practice  and  Experience,  vol. 3,  no. 2  (April-June  1973)  pp.  145-150. 

A  brief  description  of  the  testing  of  the  operating  system 
described  in  [Brinch  Hansen  70],  The  difficulties  of  testing  such 
a  system  are  noted.  The  testing  mechanism,  consisting  of  two  very 
short  additions  to  the  system  kernel  code,  was  designed  before  the 
code  for  the  system  was  written.  Since  the  system  was  designed  in 
a  series  of  nested  "programming  layers,"  each  layer  is  tested  and 
debugged  by  init iali-zing  the  system  with  a  set  of  test  processes 
which  provide  tests  of  all  of  the  functions  of  the  particular 
layer.  The  need  for  a  "systematic  set  of  reproducible  test  cases" 
as  part  of  the  documentation  of  any  large  program  is  noted. 


BR0WN73  CP26,746  1*7 

Brown,  A.R.,  Sampson,  W.A.;  Program  Debugging;  American  Elsevier, 
New  York,  (1973),  pp. 1-166. 

A  short,  easily  read  text  which  discusses  some  of  the  problems  and 
techniques  for  debugging  large  programs.  It  is  a  bit  vague  -  even 
though  an  example  is  given  of  a  proposed  method  of  bug  correction. 
It  gives  a  quick  overview  for  someone  new  to  the  field,  but 
provides  little  that  is  original.  The  article  by  P.C,  Poole 
fP00LE73]  is  better. 


BURSTALL69a  CRIB, 495  2*15 

Burstall,  R.M.;  Proving  Properties  of  Programs  by  Structural 
Induction;  The  Computer  Journal,  vol. 12,  no. 1  (February  1969) 
pp. 4 1 -48  , 

This  paper  presents  the  technique  of  structural  induction  for 
proving  the  validity  of  the  type  of  programs  where  repetition  is 
accomplished  by  recursion,  and  jumps  and  assignment  are  avoided. 
The  author  considers  the  technique  of  structural  induction  a  very 
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powerful  tool  which  is  easy  to  use  and  gives  a  clear  explanation 
in  ordinary  mathematical  terms  of  why  a  program  works  as  it  does. 
The  technigue  depends  on  the  structure  of  the  data  manipulated  b 
the  program,  and  the  objective  is  to  prove  not  just  that  th 
program  works  for  specimen  input  data  but  that  it  will  work  in 
general  for  an^r  input  data. 

The  author  feels  that  the  first  step  should  be  to  devise  methods 
of  proof  of  validity  of  non-trivial  programs  in  a  comprehensible 
manner.  The  reasoning  might  later  be  formalized  to  a  point  where 
it  can  be  performed  by  a  computer  to  provide  mechanized  debugging 
aids. 


The  main  aim  of  the  paper  is  to  suggest  some  syntactic  devices  for 
writing  programs  in  a  way  which  facilitates  the  derivation  of 
proofs  by  structural  induction.  The  form  of  t 
then  be  similar  to  that  of  the  corresponding  programs, 
believes  that  the  discipline  of  stating  theo 
proofs  will  greatly  improve  programming  education  and  practice. 
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BUFSTALL69b 


1*14 


Burstall,  P.M.,  Landin,  P.J.;  Programs  and  their 
Algebraic  Approach;  in  Meltzer,B.,  Michie,D.  (eds) , 


Proofs:  an 
Machine 


Intelligence  4,  American  Elsevier  Publishing  Co., 
43. 


(1969) ,  pp. 17- 


An  excellent  introduction  for  someone  interested  in  the  algebraic 
techniques  of  proving  program  correctness.  The  first  half  of  th^ 
paper  presents  all  the  algebraic  background  necessary  for  the 
actual  development  of  the  proofs  in  the  final  section.  Many  small 
examples  are  given  as  the  techniques  are  presented.  The  paper 
ends  with  a  proof  of  a  small  compiler  that  compiles  arithmetic 
expressions.  A  good  preparation  for  later  papers  on  the  same 
subject. 


BIJPSTALL72 


CP2S,707 


1*13 


Burstall ,  R . M.  ; 

Programs  which  Alter  Data 
(1972) ,  pp. 23-60. 


Some  Techniques  for  Proving  Correctness  of 


Structures;  2/ 


This  paper  extends  the  work  of  Floyd  [FLOYD67a]  and 
providing  techniques  for  provinq  program  correctness  in 
that  deal  with  data  structures  like  arrays,  lists,  and  binary 
trees.  The  paper  reviews  Floyd's  technique  of  using  flow  diagrams 
in  correctness  proofs.  Then,  after  describing  some  new 
which  deal  with  handling  the  data  structures,  Burstall 
several  examples  of  program  proofs  using  Floyd's  method. 
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CLINT72 


1*10 


Clint,  M.,  and  Hoare,  C.A.R.; 
Functions;  Acta  Informatica,  vol.  1 


Program  Proving:  Jumps 

no.  3,  (1972),  pp.  2  14-  224. 


and 


9 


><  O' 
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The  author  argues  for  the  validity  of  using  the  'goto'  construct 
in  two  special  cases,  namely,  as  a  means  of  exiting  a  very  deep 
loop  nest  and  as  a  failure  exit.  His  argument  is  supported  by  a 
proof  method  for  this  restricted  class. 

A  discussion  of  functions  and  function  calls  examines  the  special 


problems  that  these  constructs  present 
leads  to  a  method  to  handle  these  cases. 


to  program  proofs,  and 


The  paper 
outlined , 


concludes  with  an  example  illustrating  the  methods 


CLTNT73  CR27,211  I’f'S 

Clint,  M. ;  Program  Proving;  Coroutines;  Acta  I 
pp. 50-63 . 

This  paper  discusses  an  extension  to  the  proof 
given  by  Hoare,  so  that  Simula-like  coroutines 
The  new  proof  rule  is  stated  and  its  use 
example.  The  paper  is  not  of  much  interest  to  tl 
for  it  adds  no  new  concepts  to  previous  work.  However,  this  is 
not  to  say  the  paper  is  without  content  and  it  is  interesting  to 
know  that  the  methodology  can  be  extended  to  further  constructs. 
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DIJKSTRA65b 


CP9,023 


8«8 


Dijkstra,  E.W.;  Solution  of  a  Problem  in  Concurrent  Programming 
Control;  Communications  of  the  ACM,  vol.8,  no. 9  (1965)  pp.569. 

This  paper  presents  an  algorithm  which  ensures  that  at  any  moment 
one  and  only  one  of  a  number  of  mainly  independent  sequential 


cyclic  processes 
other  is  engaged 


with  restricted  means  of  communications  with  each 
in  the  "critical  section"  of  its  cycle. 


DIJKSTBA68d 

Dijkstra,  E. W.  ; 
Correctness;  BI' 


CP  16,717 


7*16 


A  Constructive  Approach  to  the  Problem  of  Program 
,  vol.8,  no.  3  (  1968)  pp. 174-186. 


Dijkstra  states  that  there  are  two  ways  to  establish  the 
correctness  of  a  program.  As  an  alternative  to  a  posteriori 
techniques  this  paper  proposes  that  a  priori  correct  programs  can 
be  produced  by  controlling  the  process  of  program  generation  in  a 
manner  that  is  demonstrated  on  a  simple  problem. 


DTJK5;TPA71a 

E.  W. 


5*17 


Dijkstra,  E.W.;  Concern  For  Correctness  as  a  Guiding  Principle  for 
Program  Composition;  in  Hugo,  J.S.  (ed) ,  The  Fourth  Generation, 
Tnfotech  Ltd,,  Berkshire,  England  (1971)  pp, 357-367. 


In  this  state-of-the-art  report,  Dijkstra  reviews  the  current 
state  in  the  programming  world,  and  notes  the  unfortunate 
situation  with  respect  to  programming  and  debugging  practices.  As 
an  alternative  to  this,  he  proposes  and  presents  a  strong  argument 
for  a  structural  approach  to  the  construction  of  "intellectually 
manageable"  programs  which  yields  correctness  proofs  with  much 
less  effort. 


DIJKSTRA73  1*18 

Dijkstra,  R.W.;  A  Simple  Axiomatic  Basis  For  Programming  Language 
Constructs;  FTD3'72,  Technological  University,  Eindhoven  (1  973  ). 

An  axiomatic  basis  for  programming  language  constructs  and  their 
impact  on  efforts  to  prove  programs  correct  is  discussed. 
Starting  with  the  desired  result  expressed  as  a  postcondition 
predicate  P,  he  derives  the  weakest  precondition  for  a  cons  true t 
such  that  after  execution  of  the  construct,  P  is  satisfied.  The 
axioms  for  the  derivations  are  described  for  many  (including  the 
most  useful)  constructs,  including  recursion.  The  main  advantage 
of  this  approach  is  that  it  appears  mathematically  simpler  than 
similar  approaches  to  this  problem. 


D0NAHTJE75  1*15 

Donahue,  J.E.;  Mathematical  Semantics  as  a  Complementary 
Definition  for  Axiomat ical ly  Defined  Programming  Language 
Constructs;  in  Three  A^pproaches  to  Reliable  Software:  Language 
Design,  Dyadic  Specification,  and  Complementary  Semantics; 
Technical  Report  44,  Computer  Systems  Research  Group,  University 
of  Toronto  (January  1975)  . 

Hoare’s  axiomatic  definitions  of  programming  language  semantics 
have  been  the  most  fruitful  approach  to  proving  program 
correctness.  In  certain  other  respects,  however,  the  axiomatic 
approach  has  proven  deficient:  it  may  conceal  certain  semantic 
aspects,  and  it  does  not  provide  a  useful  implementation  model. 
Professor  Donahue  argues  that  the  "mathematical  semantics"  of 
Scott  and  Strachey  provides  a  useful  complementary  definition 
technigue  to  the  axiomatic  approach.  The  guestion  of 
demonstrating  the  consistency  of  mathematical  and  axiomatic 
definitions  is  addressed. 


ELSPAS71  2*15 

Elspas,  R.,  Green,  M.W.,  and  Levitt,  K.N.;  Software  Reliability; 
Computer,  vol.4,  no.  1  (January/  February  1971)  pp. 21-27. 

In  this  article  we  have  an  overview  of  the  general  streams  of 
software  reliability.  The  first  area  discussed  is  that  of  language 
design  where  *he  authors  present  a  case  for  a  wide  range  of 
program  checking  devices  which  would  enforce  discipline  on  a 
program.  The  second  area  considered  is  that  of  semantic  checking. 
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where  a  case  is  presented  for  checkinq  the  semantics  of  code  via 
automatic  path  testing.  Lastly,  the  authors  take  a  brief  look  at 
automatic  program  verification.  Some  informal  proof  techniques 
are  examined  in  some  detail  with  a  proof  for  a  small  piece  of  code 
being  provided.  ?•  brief  summary  is  given  of  the  more  formal  proof 
techniques . 


ELSP^S'72  CR2f,196  4*16 

Flspas,  P.,  Levitt,  K. N. ,  Waldinger,  R.J.  and  Wakeman,  A.;  An 
Assessment  of  Techniques  for  Proving  Program  Correctness; 
Computing  Surveys,  vol.U,  no. 2  (June  1972)  pp. 97-147. 

An  excellent  survey  of  proof  t^^chniques  of  interest  to  both  the 
person  unexposed  to  program  verification  techniques  and  as  an 
overview  for  the  person  actively  interested  in  this  area.  The 
article  reviews  both  formal  and  informal  approaches  to  program 
verification  in  some  detail,  including  work  by  Floyd,  Hoare, 
Manna,  London  and  many  others. 


EVANS65 


CP8, 257 


1*8 


Evans,  T.G.,  and  Parley,  P.L.;  Debug  -  an  Extension  to  Current 
Online  Debugging  Techniques;  Communications  of  the  ACM,  vol.8, 
no. 5  (1965)  pp. 321-326. 


EVANS  6 6 

Evans,  T.G.,  and  Darley,  D.L.;  On-line  Debugging  Techniques:  A 
Survey;  Proceedings  of  the  FJCC,  vol.  29  (1966)  pp. 37-50, 


PLOYDf'^a  5*13 

Floyd,  P.W.;  Assigning  Meanings  to  Programs;  Proceedings  of  a 
Symposium  in  Appli<='d  Mathematics,  American  Mathematical  Society, 
vol. 19,  (1967) ,  pp. 19-32. 

Described  is  a  system  of  associating  propositions  in  a  first  order 
predicate  calculus  with  each  ’’arrow”  in  a  program  flowchart.  The 
propositions  are  us^d,  along  with  some  axioms  presented  in  the 
paper,  to  prove  statements  abou-’-  the  properties  of  commands  in  a 
program.  The  author  deals  specifically  with  proving  claims  about 
the  ranges  of  variables  in  a  program.  Such  a  proof  could  then  be 
used  in  a  proof  of  program  correctness.  Also  dealt  with  is  a 
technique  of  proving  program  termination. 

This,  in  combination  with  a  paper  by  Purstall  [  BriRSTALL72  ], 
provides  a  strong  algebraic  system  for  proofs  of  programs.  It  is 
clear,  however,  that  the  author’s  technique  is  rather  tedious  and 
may  not  be  of  great  value  in  proofs  of  large  programs. 


-R  1- 


FL0YD67b  2*12 

Floyd,  P.W.;  The  Verifying  Compiler;  Carneg ie-Mellon  nniver'^ity. 
Department  of  Computer  Sc ience (Deoe mber  1D67), 


FL0YD72  CF2R,232  7*16 

Floyd,  P.W.;  Toward  Interactive  Design  of  Correct  Programs; 
Proceedings  of  TFTP  Congress  71,  vol.  1  (1972)  pp.7-10. 

An  imagined  interaction  between  a  computer  programmer  and  his 
machine  is  described,  in  which  the  compu'*-er  checks  the  program  for 
consistency  with  the  programmer’s  stated  intentions,  and  proves 
the  logical  or  semantic  correctness  of  the  program  at  various 
levels. 


FONG  7  3 

Fong,  E.N,;  Improving  Compiler  Diagnostics;  Datamation,  vol.  19, 
no.  U  (April  19*73)  pp.8U-86. 

Most  of  a  programmer's  effort  in  program  development  is  spen-*-  in 
debugoing.  The  author  suggests  some  debugqing  and  monitoring 
facilities.  These  are  divided  into  three  different  groups. 
Compile-time  checks  include  syntax  checking,  cross  reference 
listing,  modularity,  paragraphing,  and  static  control  concordance, 
■formal  and  actual  argument  checks  and  static  subroutine  analysis 
can  be  performed  at  link/load  time.  Execution- -^ime  checks  include 
dynamic  traces  of  subroutine  calls,  flow  of  control,  and  variables 
in  addition  -^o  snapshot  dumps  and  address  checking. 


GAINESe^  2*13 

Gaines,  P.S.;  '^he  Debugging  of  Computer  Programs;  Ph.D.  Thesis, 
Princeton  University,  Dopartm‘^nt  of  Electrical  Engineering  (  1969) 
pp. 1- 169 . 

This  thesis  is  a  general  study  of  tools  and  techniques  for 
debugging  programs,  and  the  design  of  compilers  and  op'^r at i ng 
systems  to  facilitate  debugqing.  It  includes  an  analysis  of  the 
programming  process  to  identify  carefully  what  the  problems  are  in 
debugging  and  how  they  arise.  Based  on  this  analysis,  the 
fundamental  notions  which  underlie  most  debugging  aids  are 
identified.  The  facilities  that  are  currently  available  to 
programmers  using  batch  operating  systems  are  discussed,  and  a 
number  of  new  ones  are  presented. 


GOOD70  CP20,339  3*11 

Good,  D.I.;  Toward  a  Man-Machine  System  for  Proving  Program 
Correctness;  Ph.D.  Thesis,  University  of  Wisconsin,  Department  of 
Computer  Science  (1970). 


-8  2- 


The  problem  considered  is  the  realization  of  a  computerized 
progra m- proving  system  that  is  applicable  to  real  computer 
programs.  '^'he  inputs  to  the  system  are  a  program  and  the 
specifications  this  program  must  meet  in  order  to  be  correct.  Tf 
the  program  actually  is  correct,  then  the  system  should  either 
prove  that  the  program  is  correct,  or  at  least  provide  assistance 
so  that  provina  correctness  becomes  a  feasible  task  for  a  human. 
If  the  program  is  not  correct,  the  system  should  assist  in 
locating  errors  in  the  program.  The  total  question  of  the 
practical  realization  of  proving  the  correctness  of  programs  is 
considered  from  three  levels.  At  the  first  level,  a  simple  model 
that  can  describe  a  significant  class  of  real  programs  is 
developed.  Based  on  this  model,  the  idea  of  a  result  of  a  program 
is  formalized.  The  second  level  is  a  general  method  for  proving 
program  results,  the  inductive  assertion  method.  The  third  level 
is  the  realization  of  a  man-machine,  interactive  program  proving 
system  through  a  partial  automation  of  the  inductive  assertion 
method . 


G0ULD71  CR22,292 

Gould,  J.S. ;  On  Automatic  Testing  of  On  Line  Real  Time  Systems; 
Proceedings  of  the  SJCC,  vol.  .18  (1971)  pp.  477-484. 


G0ULD7.1  1*16 

Gould,  T.D. ;  Some  Psychological  Evidence  on  How  People  Debug 
Computer  Programs;  RC  4542  (7  B20208) ,  IBM  Thomas  J.  Watson 
Research  Center,  Yorktown  Heights,  New  York  (September  1973)  pu. 1- 
5  3. 

This  paper  reports  the  results  of  a  study  on  how  experienced 
Fortran  programmers  from  the  IBM  Research  Center  debugged  Fortran 
programs  which  contained  single-line  errors.  Two  motivations  for 
the  experiment  were  to  analyze  and  report  on  various  debugging 
strategies,  and  to  compare  the  way  programmers  debugged  when 
allowed  to  use  interactive  debugging  tools.  Results  included 
observations  that 

1)  ’’Highly  motivated”  subjects  could  debug  the  programs  as 
efficiently  when  they  just  examined  the  listing  as  they  could  when 
they  had  access  to  what  had  been  considered  aids; 

2)  Subjects  found  meaningful  mnemonics  useful  in  debugging. 

3)  Bugs  in  assignment  statements  were  the  most  difficult  to  debug, 
primarily  because  subjects  had  to  have  a  mere  thorough 
understanding  of  the  substance  of  the  program. 

Studies  of  this  nature  are  open  to  a  great  number  of  criticisms. 
One  criticism  concerns  the  conclusion  that  programmers  didn't  seem 
to  use  what  were  considered  debugging  aids;  the  reasons  for  not 
using  the  interactive  system  provided  were  too  numerous  (lack  of 
programmer  familiarity  and  poor  design  of  the  interactive  system, 
to  name  two)  to  support  such  conclusions  very  strongly.  On  the 
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whole,  however,  the  paper  seems  useful  in  providing  a  documented 
study  of  the  programming  process,  and  shedding  some  light  on  the 
debugging  task. 


GRAHAM 73 a 


1*12 


Graham,  S.L.,  and  Rhodes,  S.P.; 
in  Compilers;  ACM  Symposium 
Languages,  Boston,  Mass.  (Oct. 


Practical  Syntactic  Error  Recovery 
on  Principles  of  Programming 
1973)  pp. 52-58. 


of  error  detection  and  recovery  to 
detected”  and  ’’minimize  the  number 

tl 


The  article  proposes  a  method 
’’maximize  the  numbers  of  errors 
of  times  it  reports  an  error  when  there  is  none,”  The  aim  of  the 
system  is  thus  to  minimize  the  number  of  runs  needed  to  debug  a 


program  with  syntax  errors.  The  method  is 
condensation  phase  where  the  system  tries 
the  error  and  continue  parsing,  and 
attempts  to  correct  the  error. 


composed  of  two  parts:  a 
to  locally  recover  from 
a  correction  phase  which 


GRISHMAN70  CR19,806  2*8 

Grishman,  R.  ;  The  Debugging  System  ’’AIDS”;  Proc.  SJCC,  vol.36 

(1970)  pp. 59-64. 

The  author  presents  a  description  of  a  FOETRAN-like  debugging 
language  which  has  been  implemented  on  the  CDC  6600. 

It  is  applied  to  compiled  code  rather  than  being  a  source  language 
interpreter.  As  such,  it  is  far  more  useful  when  debugging  large 
programming  systems.  The  extensive  features  of  AIDS  do  reguire  a 
machine  as  large  as  the  CDC  6600  for  implementation,  however. 

The  effort  spent  in  developing  such  a  powerful  debugging  sys-’-.em 
may  say  something  for  the  benefits  or  dangers  of  using  FORTRAN. 


GPISHMAN71 


5*  1  2 


Grishman,  R.  ;  Criteria  For  A  Debugging  Language;  in  Rustin, 
R.  (ed.),  Debu^^in^  Techniques  in  Large  Systems,  Pren tice -Ha  1 1 
(1971)  pp757-75. 


The  features  of  a  good  debugging  system  language 
compared  with  current  debugging  facilities  (both 
interactive  systems)  .  '’’he  various  implem 

interactive  debugging  system  are  compared  accordi 
determination  of  compiler  and  assembly  language 
specific  checks,  and  ease  of  modifications.  An 
author’s  own  debugging  system,  AIDS,  is  presente 
of  a  sample  debugging  run  using  AIDS  is  given. 
AIDS  is  questioned  because  of  the  difficult! 
loading  the  language  for  time  sharing  use  and  lea 
complicated  system. 
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HANFOPD70  CR21,221 

Hanford,  K.V.;  Automatic  Generation  of  Test  Cases;  IRM  Systems 
Journal  vol.9,  no, 4  (1970)  pp, 242-257, 

Hanford  describes  his  "syntax  machine."  This  is  a  program,  which 
he  has  implemented  on  S/360,  which  produces  programs  which  are 
syntactically  correct  (but  meaningless).  These  programs,  which 
can  be  used  for  testing  compilers,  may  be  produced  either  pseudo- 
randomly,  or  exhaustively.  He  introduces  what  he  calls  a  "dynamic 
grammar"  which  allows  the  user  to  provide  for  the  context 
sensitivity  (e.g.,  variables  must  be  declared)  of  the  language 
being  generated. 
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ms  which  use  the  WATFOR  compiler, 
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Hoare,  C.A.R,;  Proof 
ACM,  vol,14,  no. 1  (Jan. 


of  a  Program:  FIND;  Communications  of 
1971)  pp. 39-45. 


the 


example  of 
correctness  , 


concurrent  program 
Hoare  mentions  some 


An  non-trivial 

construction  and  proof  of 
disadvantages  and  weaknesses  to  this  approach,  but  he  obviously 
feels  that  such  formal  proofs  are  extremely  important  and  that 
eventually  computer  assistance  may  be  possible. 


HOARE 7 2c  1*18 

Hoare,  C.A.R. ;  Proof  of  Correctness  of  Data  Representation;  Acta 
Tnfor matica-I ,  Springer-Verlag,  (1972),  pp, 271-281. 


Hoare  proposes  that  one  should  develop  algor 
data  concepts,  and  choose  a  representation  for 
design  is  finished.  In  this  paper  he  discu 
proving  that  the  concrete  representation  chosen 
to  the  requirements  of  the  abstract  conce 
methodology  of  SIMULA  data  constructs  and  provi 
proof . 
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HOBNINGTUb  1*17 

Horning,  J,J.,  Lauer,  H.C.,  Melliar-Smith,  P.M,,  and  Randell ,  B,  ; 
A  Program  Structure  for  Brror  Detection  And  Recovery;  University 
of  Newcastle  Upon  Tyne,  Computing  Laboratory,  Technical  Report 
Series,  no, 59,  (April  1974),  pp,1-16. 


This  paper  presents  a  structured  formalism  and  an  assoc 
recovery  machine  for  dealing  with  hardware  and  software  error 

On  the  premise  that  error  detection  and  recovery  is  useful 
authors  develop  the  "Recovery  Block"  construct  which  includes 
intended  operation,  a  testing  mechanism,  and  an  associated  s 
"alternative  blocks,”  "Recovery  blocks”  can  be  nested 

structured) ,  This  suggests  a  stack-like  mechanism  be  used  to 
track  of  variables  (and  pathways)  for  recovery.  The  au 
present  the  "recursive  cache”  as  a  reasonable  implementati 
such  a  mechanism.  The  "recursive  cache”  only  keeps  trac 
changed  (written)  variables.  Recovery  proceeds  by  restorin 
changed  "recovery  block”  variables  and  entering  an  approp 
"alternative  block,” 
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A  more  complex  form  of  this  scheme,  "recoverable  procedures 
proposed  for  recovery  from  the  more  typical  systems  environ 
involving  operations  other  than  assignment.  The  authors  ind 
some  ongoing  implementation  efforts,  (Perhaps  the  significan 
error  recovery  design  in  software  systems  is  understated,) 
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jrNSSON68  CR16,001  1*9 

Jonsson,  S,I,;  On-line  Program  Debugging;  BIT,  vol,  8,  no,  2 

(1968)  pp, 122-127. 

JOSEPHS69  CR18,88P 

Josephs, W , H. ;  An  On-line  Machine  Language  Debugger  for  OS/360; 
Proceedings  of  the  FJCC,  vol,  35  (1969)  pp,  179-186. 


KAHN7 1 


1*10 


Kahn,  0,;  An  Approach  to  System  Correctness;  Proceedings  of  the 
Third  ACM  Symposium  on  Operating  Systems  Principles  (Oct. 1971) 
pp. 86-94 . 
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Dealing  with  systems  of  a  finite  number  of  processes,  the  author 
discusses  several  approaches  to  describing  a  system  and  proving 
its  correctness.  ?^s  usual,  success  is  claimed  for  the  chosen 
methods  when  they  are  shown  capable  of  dealing  with  Di jkstra- esque 
examples;  in  this  case  semaphores  and  the  hungry 
philosophers/slippery  spaghetti  problem. 


KING71a 
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King,  J.C.;  Proving  Programs  to  be  Correct;  IEEE  Transactions  on 
Computers,  vol.C-20,  no. 11  (Nov.  1971)  pp.  1 3 3  1- 1 336 . 
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7*1U 


King,  J.;  A  Verifying  Compiler;  in  Eustin,  P 
in  5 y ste ms ,  Prentice-Hall,  Inc. 


(ed.)  , 
(1971) 


Debugging 
pp. 1 7-40 . 


In  this  article,  a  special  compiler  i 
only  compiles  a  program,  but  allows  you  t 
will  always  execute  correctly.  For 
sample  program  to  be  compiled  is  annota 
relations  among  its  variables  are  made, 
between  these  propositions,  as  the  flow  o 
then  the  program  is  verified  to  be  corr 
found,  information  concerning  errors  is 
acted  upon. 


s  described,  one  that  nc 
o  prove  that  the  progra 
illustration  purposes, 
ted.  Propositions  aboi 
If  consistency  is  four 
f  the  program  is  traced 
ect.  If  inconsistency  i 
discovered,  and  can  I 


The  importance  of  programs  that  always  execute  correctly  can  not 
be  denied.  Although  the  ideas  presented  are  significant,  much  of 
this  work  has  been  very  theoretical.  The  reader  is  not  told  how  to 
write  assertions  for  programs,  or  how  to  correct  invalid 
assertions.  Much  work  is  needed  in  this  area. 
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Kulsrud,  H.E.;  HELPER:  An  Interactive  Extensible  Debugging  System; 


Proceedings  of  ACM  Second 
Principles  (October  1969)  pp 


Symposium 

105-111. 


cn  Operating  Sy  stems 


HELPER  is  a  semi-sophisticated  graphical  on-line  debugging  system 
intended  for  use  with  low-level  languages.  A  command  language 
compiler  is  utilized  with  access  to  problem  program  symbol- tables 
and  other  data.  Little  mention  is  made  of  the  effect  of  this 
system  on  programming  habits  except  to  state  that  its  use  is 
somehow  addictivf=.  That  is  not  necessarily  a  recommendation. 


KULSRUD7 1 


CR23,015 


5*1  1 


Kulsrud,  H.E.;  Extending  the  Interactive  Debugging  System  Helper; 
in  Rustin,  R.  (ed.),  Debug^ina  in  Larg;e  Systems , 

Prentice-Hall,  Inc.  1971)  pp, 77-91. 
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LAFRANCE71  1*11 

LaFrance,  J.F.;  Syntax-directed  Error  Recovery  for  Compilers;  Ph, 
D.  Thesis,  University  of  Illinois  at  Urbana-Champaiqn ,  Department 
of  Computer  Science  (1971)  pp.  1-162. 
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LAMPSON7 1 

Lampson,  B.W.;  On  Reliable  and  Extendable  Operating  Systems;  in 
Hugo,  J.S.  (ed.).  The  Fourth  Generation,  Infotech,  Ltd., 
Berkshire,  England  (1991)  pp,U21-444. 


LANDY71  CR22,447 

Landy,  R.  ,  and  Needham,  R.M.;  Software  Engineering  Techniques  used 
in  the  Deve  lopmen-*-  of  the  Cambridge  Multiple- Access  System; 
Software- Practice  and  Experience,  vol.1,  no. 2  (Aprii-June  1971) 
pp. 167-173. 

Testing  and  development  of  elaborate  systems 
assistance  of  sophisticated  techniques  and  softw 
several  stages  in  the  process.  These  include  systems 
and  manipulating  source  text,  producing  and  testing 
in  a  realistic  but  "safe"  environment  and  arranging 
compatible  fall-back  process  to  a  previous  version 
unforeseen  difficulties.  The  paper  describes  a  n 
aids  that  have  been  found  useful  during  the  develop 
Cambridge  Multiple-Access  system. 

LANZARONE72 

Lanzarone,  G.A.;  Proof  of  Program  Correctness:  a  Review;  Honeywell 
Computer  Journal,  vol,6,  no. 1  (1972)  pp. 38-42. 
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Lanzaron®  gives  a  concise  review  of  the 
program  correctness*  He  briefly  describes  and 
verification  schemes.  The  work  of  Floyd, 
d iscussed . 
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LESTER71 

Lester,  P.P.;  Cost  Analysis  of  Debugging  Systems;  MIT,  Project 
MAC,  no.  TP-90  (September  1971)  pp. 1-112. 


LONDON70a  CP20,000 

London,  P.L.;  Bibliography  on  Proving  the  Correctness  of  Computer 
Programs;  in  Meltzer,  E.,  and  Michie,  D.  (ed.), 
Intelligence  5^;  American  Elsevir  Publishing  Company,  Inc.  (  1970) 
pp*  56  9-5  80  * 


LONDON70b  2*14 

London,  P.L.;  Bibliography  on  Proving  the  Correctnes  of  Computer 
Programs  -  Addition  No.  1;  University  of  Wisconsin,  Department  of 
Computer  Science,  no.  1C4  (December  1970)  pp.1-8. 


LONDON70C  CR21,040  5*16 

London,  P.L.;  Proving  Programs  are  Correct:  Some  Techniques  and 
Examples;  BIT,  vol.  10,  no.  2  (1970)  pp.  168-  182. 

The  advantages  and  feasibility  of  proving  program s  correc t  are 
demonstrated*  Among  the  advantages  mentioned  are  that  the 
discipline  of  the  proof  technique  provides  the  programmer  with  a 
method  of  systematically  searching  for  errors  and  that  the 
completed  proof  gives  sufficient  reason  why  the  program  must  be 
correct.  The  feasibility  of  proof  techniques  is  demonstrated  by 
exhibiting  proofs  of  five  simple  Algol  programs.  Each  proof  uses 
different  techniques  among  which  are;  case  analysis,  proof  by 
assertions,  mathematical  induction,  prose  proofs,  sect  ion- a t-a - 
time  techniques,  and  techniques  starting  with  inner  loops,  working 
out . 
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1*10 
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(May  1969),  pp. 119-127. 
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The  only  programs  considered  are  those  with  assignment 
and  conditional  jumps.  Correctness  of  programs  depends 
ermination  and  final  result,  as  does  the  equivalence  of 
Theorems  are  presented  concisely  and  rigorously  along 
illustrative  examples. 


MANNA71 


CP23, 686 


1*13 


Manna,  Z.,  and  Waldinger,  F.J.; 
Synthesis;  Communications  of  the  ACM, 
1971)  pp. 151-165. 


Toward  Automatic  Program 
vol.  14,  no.  3  (March 


MANNA73 


1*14 


Manna,  Z.,  Ness,  S. ,  Vuillemin, 
Properties  of  Programs;  CACM  Vol 


502. 


Inductive  Methods  for  Proving 
No. 8,  (August  1973),  pp.491- 
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MCCARTHY67 

McCarthy,  J. ,  and  Painter,  J.A. ;  Correctness  of  a  Compiler  for 
Arithmetic  Expressions;  Mathematical  Aspects  of  Computer  Science 
(1967)  pp. 33-41. 


MOPPIS73 


1*10 


Morris,  F.L.;  Advice  on  Structuring  Compilers  and  Proving 
Correct;  A.C.M.  Symposium  on  Principles  of  Programming  Lanqu 
(Oct.  1973),  pp. 144-152. 

The  author  directs  his  attention  to  proving  compiler  correct 
His  approach  is  algebraic,  and  entails  defining  the  s 
language,  target  language  and  their  respective  meaning 
heterogeneous  alqebras,  then  defining  homomorphisms  (one  of 
represents  the  compiler)  between  these  algebras.  The  paper 
mostly  with  an  example  of  the  development  and  proof  of  a 
compiler.  Although  this  method  proves  to  be  very  powerfu 
requires  considerable  background  knowledge  before  it  be 
understandable.  This  is  not  an  introductory  paper  by 
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standards? ,  but  if  one  is  prepared  to  work  through  it  carefully,  it 
proves  to  be  extremely  worthwhile. 


CGDIN73  4«11 

Ogdin,  J.L.;  Improving  Software  Reliability;  Datamation,  vol.19, 
no.1  (Jan,  1973)  pp. 49-52. 

This  paper  tri^s  to  develop  ways  for  improving  software 
reliability,  using  modular  programming.  '^he  author  first  makes  a 
general  comparison  of  a  program  to  a  mathematical  function, 
showing  the  many  similarities  that  exist,  and  then  narrows  this 
comparison  to  tasks  and  modules. 

In  an  effort  to  provide  for  more  reliable  software,  the  author 
discusses  several  relevant  areas,  such  as  where  the  decisions 
should  be  made  in  hierarchies  of  tasks  and  the  problem  of  changing 
specifications  for  written  modules.  When  the  modules  are 
redefined,  they  should  be  renamed.  Finally,  program  bugs  are 
classified  and  then  reasons  and  solutions  are  given  for  them. 


POOLS73  CR26,539  1*12 

Poole,  P.C. ;  Debugging  and  Testing;  in  Bauer,  F.L.(ed,),  Advanced 
Course  on  Software  Engineering;  S pringer- Verlag,  New  York,  (1973), 
pp . 27  8-3 1 8 . 

The  author  points  out  that  since  every  program  written  will  have 
errors,  it  is  most  important  that  programmers  write  their  programs 
allowing  for  ease  of  subseguent  testing  and  debugging  (unlike 
present  practice,  which  tends  to  assume  the  program  will  work 
without  error) .  He  suggests  planning  for  the  testing  and 
debugging  phases.  In  particular,  "debugging  code"  should  be  pu-^ 
in  right  at  the  start  --  rather  than  having  it  inserted  when  bugs 
arise.  The  most  useful  form  of  debugging  code  would  be  one  which 
would  remain  in  the  program  in  its  final  form,  but  would  not  be 
executed  unless  desired  (when,  for  example,  a  new  bug  appears). 
The  use  of  debugging  code,  a  modular  program  structure,  and 
parameterization  of  important  variables  would  make  testing  and 
debugging  much  easier.  A  discussion  is  given  of  classical 
debugging  technigues  --  most  of  which  have  the  problem  of 
generating  too  much  output  in  an  awkward  form  for  analysis.  On¬ 
line  debugging  seems  popular,  but  has  problems  (principally,  how 
to  manipulate  compiled  code) ,  New  debugging  and  testing  aids 
should  also  take  into  account  the  fact  that  corrections  to  present 
programs  are  often  not  fully  tested  or  documented  because  the 
debugging  and  testing  methods  are  awkward  and  time  consuming. 


PR0K0P73  CR25,529 

Prokop,  J.S.;  On  Proving  the  Correctness  of  Computer  Programs;  in 
Hetzel,  W.C.  (ed«);  Program  Test  Methods;  Prentice-Hall,  Englewood 
Cliffs  (1973)  pp. 29-37. 
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Rain,  W.;  Two  Unusual  Methods  for  Debugging  System  Software; 
Software-Practice  and  Experience,  vol.3,  no.1  (Jan. -Mar.  1973) 
pp. 6 1 -63 , 
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The  correctness  of  software,  and  thus  its  reliability,  is 
to  some  criteria.  These  criteria  should  be  part  of  the 
specifications  and  design  of  the  system.  Nevertheless, 
systems  should  have  provisions  for  coping  with  softw 
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In  conclusion  Randell  states  that  "the  most  vital  task  to  be 
undertaken  in  designing  a  computing  system  for  a  highly  critical 
and  complex  environment  is  that  of  attempting  to  minimize  the 
extent  to  which  reliance  is  put  on  the  correct  and  continuing 
functioning  of  the  system." 


RANDELL72 

Pandell,  B. ;  Operating 
Reliability;  Proceedings 
PP.281-2B0. 


CR25,107  3*11 

Systems:  The  Problems  of  Performance  and 
of  IFIP  Congress  71,  vol.  1  (1972) 


pnSTTN71  CR22,801  1*15 

Rustin,  R,  (ed.);  iH  LUS®  Systems;  Prentice- 

Hall,  N.J.  (1971)  pp. 1-141. 


SATTERTHWAITE'72  CR24,408  1*15 

Satterth waite ,  E.;  Debugging  Tools  for  High-Level  Languages; 
Software  -  Practice  and  Experience,  vol. 2,  no. 3,  (July- Sept  ember 
1 972) ,  pp. 197-217. 

This  article  stresses  the  need  for  reviving  the  dialogue  between 
man  and  machine,  which  was  lost  in  the  transition  to  higher-level 
languages.  As  an  example  of  a  modest  but  significant  step  toward 
such  a  revival,  the  author  describes  a  programming  system  usirg 
Algol  W  "which  supports  a  range  of  debugging  tools  and  techniques, 
all  based  entirely  upon  the  high  level  language  used  by  the 
programmer."  Four  design  criteria  were  specified: 

1)  All  information  to  the  user  should  be  expressed  in  terms  of  his 
program  and  Algol  W. 

2)  The  compiler  should  produce  machine  code,  which  should  not  be 
significantly  degraded  by  debugging  requirements,  and  which  should 
execute  at  full  hardware  speed  when  net  in  debugging  mode. 

3)  Resource  requirements,  especially  I/O,  should  be  moderate 
enough  for  use  by  students  with  limited  budgets. 

4)  Debugging  tools  should  be  easy  to  invoke,  and  default 
information  should  encourage  programmers  to  critically  re-examine 
their  programs,  as  well  as  help  programmers  in  diagnosing  program 
failure. 

Discussed  were  system  organization  and  aspects  of  the  /360 
implementation  of  the  debugging  system.  Performance  of  this 
implementation  was  evaluated  for  Algol  W  programs  chosen  from  a 
variety  of  diverse  applications. 

The  system  is  not  the  programmer's  answer  to  debugging,  but  it  has 
gone  a  significant  way  in  providing  an  example  of  useful,  easy-to- 
invoke  feedback  +0  those  programming  in  high-level  languages. 
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SCHWAPTZ71  9*12 

Schwartz,  J.  ;  T^r.  Overview  of  Bugs;  in  Eustin,  R.(ed.),  Debu  gging 
Techniques  in  Lar^e  S^stenis,  Pren *ice- Hall  (1971)  pp,1-16, 

Tn  this  article,  a  classification  of  bugs  is  outlined  including 
type,  frequency,  and  habitat.  The  ’’process  of  bug  extermination” 
is  review<=d,  and  suggestions  for  improvement  of  debugging  tools  is 
discussed.  Structure  of  programs  and  proofs  of  program 
correctness  are  examined.  The  dimensions  of  time  and  space  in  the 
debugging  process,  as  well  as  an  ideal  debugging  language  are 
considered . 


SMITH72a 


CP24 ,582 


2*14 


Smith,  J.M.:  Proof  and  Validation  of  Program  Correctness;  The 
Computer  Journal,  vol.15,  no. 2  (May  1972)  pp.  130-131. 


The  author  points  out  that  ever  since  1962 
the  concept  that  programs  should  be  proved 
merely  verified,  considerable  effort  has  been 
of  techniques  for  producing  such  proofs.  So 
has  been  made  although  this  effort  has 
programming  languages,  theory  of  algorithms. 


when  McCarthy  raised 
correct  rather  than 
devoted  to  the  study 
far  little  progress 
lead  to  advances  in 
and  system  theory. 


The  author  proposes  that  it  may  not  be 
correctness  of  practical  programs  rigorously 
definition  of  program  correctness  as  stated 
basis  of  this  definition  is  the  concept  of  a 
•desired  result*.  Tn  general  i-’-  is  not  alw 
this  desired  result  and  the  author  proposes 
program  validation  by  which  program  errors 
confidenc‘=“  level  of  a  program  increased. 
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enough  to  satisfy  th‘= 
by  Manna  in  1969.  The 
program  yielding  ■’■he 
ays  possible  to  define 
other  approaches  to 
can  be  reduced  and  the 


SNOWDON70  1*15 

Snowdon,  R.;  Possible  Computer  Assistance  in  Program  Structuring 
and  Correctness;  University  of  Newcastle  Upon  Tyne,  Compu-’-ina 
Laboratory  (1  970)  . 


SNOWDON72  9*14 

Snowdon,  R.7*..;  PEARL:  An  Interactive  System  for  the  Preparation 
and  Validation  of  Structured  Programs;  SIGPLAN  Notices,  vol.7, 
no. 3  (March  1972)  pp.9-26. 

The  author  describes  a  partially  implemented  interactive  system 
whose  purpose  is  to  assist  the  programmer  in  writirg  structured 
programs.  Provisions  exist  in  PEARL  for  some  assistance  towards 
program  correctness.  The  system  restricts  its  attention  to  small, 
sequential  programs  designed  by  a  single  programmer. 

Initially,  an  ideal  "machine"  is  described,  both 
specification  of  its  data  types  and  operations,  and  by  a 


by  the 
pr  ogram 
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writtpn  for  that  machine.  The  introduction  of  further  machines 
(and  programs  for  them)  serves  to  refine  the  meaning  of  previously 
introduced  programs  and  constructs.  Conditions  may  be  given  to 
operations  in  order  to  aid  in  ensuring  program  correctness  for  a 
particular  machine. 

The  system  has  various  facilities  for  program  editing,  and 
incompletely  specified  programs  can  be  run,  as  well  as  compiled, 
with  PEARL  requesting  assistance  upon  encountering  an  operation 
which  has  not  yet  been  fully  explained. 


STOCK HAM66 

Stockham,  T.G.;  Some  Methods  of  Graphical  Debugging;  Proceedings 
of  the  IBM  Scientific  Computing  Symposium  on  Man-Machire 
Communication  (1B66)  pp. 57-68. 


SUPNIK71  CR23,017  1*B 

Supnik,  P.M.;  Debugging  Under  Simulation;  in  Rustin,  R.(ed.), 
Debugging  Z§chnigues  in  Large  Systems,  Prent ice- Hall  (1971) 
pp. *117-136. 


VANDEP  N00T71  4*8 

Vander  Noot,  T.J.;  System  Testing...  A  Taboo  Subject;  Datamation, 
vol.17,  no. 21  (Nov.  1971), 

This  article  suggests  hew  the  programmer  should  test  his  program 
to  detect  bugs  and  how  the  customer  should  test  a  received 
product. 

VAN  HORN68  CR15,580  1*8 

Van  Horn,  C.C.;  Three  Criteria  for  Designing  Computing  Systems  to 
Facilitate  Debugging;  Communications  of  the  ACM,  vol.  11,  no.  5 
(May  1968)  pp. 360-365. 


VEP  STEEG64  CR6,950  1*8 

Ver  Steeg,  R.L.;  TALK  -  A  High-Level  Source  Language  Debugging 
Technique  with  Real-Time  Data  Extraction;  Communications  of  the 
ACM,  vol.  7,  no.  7  (July  1964)  pp. 418-419. 


WALDINGER69  CP20,483  2*8 

Waldinger,  P.J.,  and  Lee,  R.C.T.;  PROW:  A.  Step  Toward  Automatic 
Program  Writing;  Proceedings  of  the  International  Joint  Conference 
on  A.rtificial  Intelligence  (1969)  pp.  241-252. 
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The  program  PROW,  is  described  whi 
an  algorithm  expressed  in  the 
predicate  calculus  and  produces 
this  algorithm.  Since  theorem  pro 
construct  these  programs,  they 
errors.  The  authors  see  this  syste 
goal  of  freeing  programmers  fro 
different  programming  languages. 
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HOOD69  CR18,331 

Wood,  D, ;  A  Proof  of  Hamblin's  Algorithm  for  Translation  of 
Arithmetic  Expressions  from  Infix  to  Postfix  Form;  BIT,  vol.  9, 
no.  1  (1969)  pp. 59-68. 
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Correctness  -  formal  approaches: 

Allen71,  Ashcroft71,  Eurstall69,  Burstall69,  Burstall72, 
Clint72,  Clint72,  Clint73,  Dijkstra73,  Elspas72,  Floyd67a, 
Floyd72b,  Good70,  Hoare69,  Hoare71a,  Hoare71b,  Hoare72a, 
Hoare72b,  Hoare72d,  King71a,  King71b,  Manna71,  Manna73, 
Morris73,  Waldinger69; 


Correctness  -  informal  approaches: 


Dijkstra65a, 
Di jkstra7 la, 
McCarthy67, 
Wood69  ; 


Pijkstra65b,  Dijkstra68c,  Dijkstra68d, 

Dijkstra72b,  Flspas72,  London70c,  London71, 
Naur66,  Naur69a,  Smith72a,  Snowdon70,  Snowdon72, 


Testing : 


Alexander71,  Balzer69,  Brinch  Hansen73a,  Brooks75,  Brown73, 
Garwick61,  Gould71,  Haney72,  Hanford70,  Lucas73,  f1ills73b, 
Needham70a,  Parnas72b,  Poole73,  Rain73,  Vander  Noot71; 
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Automatic  generation  of  test  cases: 
Elspas71,  GouldTI,  Hanford70; 


Debugging : 
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68, 

Blair71,  Brady68,  Brown73,  Burstall69, 
ns66,  Fong73,  Gaines69,  Gould73, 
Gunderman73,  Henderson72,  Jonsson68, 
,  Kulsrude69,  Kulsrud71,  Lassettre72, 
0gdin73,  Poole73,  Eain73,  Eustin71, 
wart271,  Stockham66,  Supnik71, 

Ver  Steeg64,  YohG74; 


Syntax  error  recovery: 

Graham73a,  Gries71,  Hedrick70,  LaFrance71. 
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JLI»  Evaluation 

Highly  recommendf^d :  Parnas67;  7,urcher68 


ARDEN69 

Arden,  B.W,,  and  Boettner,  D, ;  Measurement  and  Performance  of  a 
Multiprogramming  System;  Proceedings  ACM  Second  Symposium  on 
Operating  Systems  Principles  (Oct,  1969)  pp, 130-146, 


This  paper  opens  with  a  hri^f  description  of  the  Universi 
Michigan  Multi-Programming  System  (rjMMPS)  and  MTS  in  order  to 
the  foundation  for  a  discussion  of  software  measurement.  It 
describes  two  basic  types  of  measurement  (  (1)  processor  time 
elapsed  time  (2)  "microscopic"  recording  of  certain  events  o 
short  period  of  time)  and  how  they  may  be  applied  to  large  sy 
(in  particular  UMMPS) ,  Finally  a  measure  of  time  sh 
efficiency  (ideal  response  time  over  actual  resoonse  time 
introduced  and  several  tables  and  graphs  are  presented  to  di 
various  performance  characteristics. 
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Arvey ,  P , D, , 
vol,  1  ,  no , 7, 


Hoyle,  J,C,;  Evaluating  EDP  Personnel; 
(July  1973),  pp, 69-  73, 


Da  tama  tion , 


One  of  the  major  problems  in  undertaking  a  project 
large  program  is  the  reliability  of  the  personnel  in 
manager  of  such  a  project  must  have  informatio 
abilities  of  the  analysts  and  programmers  in  order 
intelligent  attempt  at  work  allocation  and  scheduling 
discusses  his  experiences  in  tackling  this  problem 
avenues  of  approach  that  a  manager  faced  with  this 
investigate. 
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Bard,  Y,;  CP-67  Measurement  and  A 

ACH/SIGOPS  Workshop  on  System  Performance 

Discusses  the  statistical  and  measure 
compare  various  releases  of  CP-67  with 
overhead,  etc.  This  paper  is  interesting 
67  is  an  easy  system  on  which  to  perform 
free  measurements.  Additionally,  the  a 
of  this  and  a  prior  study  led  to  a  re-des 
dramatic  improvement  in  performance. 


naly 

sis; 

Pr 

ocee 

ding 

s  o 

f 

Eva 

luat io 

n 

(Apr 

il  1 

971 ) 

• 

ment 

tech 

ni 

ques 

us 

ed  t 

0 

res 

pect 

to 

th 

rouq 

hput 

t 

for 

severa 

1 

reas 

ons. 

CP 

- 

rela 

ti  vely 

inte 

rf  er 

ence 

- 

ppli 

cation 

o 

f  th 

e  re 

suit 

s 

ign 

of  som 

e 

mod  u 

les 

wit 

h 

-9fl- 


BAPD72 

Bard,  Y.,  and  Sur yanar ayana,  K,V,;  On  the  Structure  of  CP-67 
Overhead;  in  Freiherger,  W,  (ed.)#  Statistical  Com  puter 
lyaluation.  Academic  Press  (1  972). 

Regression  analysis  lives  again  in  this  thrilling  tale  from  the 
annals  of  IBM’s  history.  Still,  it's  a  good  way  to  determine 
actual  software  bottlenecks,  and  those  concerned  with  producing 
efficient  real-time  programs  should  probably  be  acquainted  with 
the  uses  of  the  technique. 


BARD73  2*9 

Bard,  Y. ;  Experimental  Evaluation  of  System  Performance;  IBM 
System  Journal,  vol.12,  no. 3  (1973)  pp. 302-314. 

The  paper  reports  on  a  method  for  testing  system  performance, 
developed  to  he  used  as  part  of  an  evolutionary  operation 
technique  to  improve  systems. 

The  performance  of  different  features  of  the  system  are  tested  by 
using  rapid  on-line  switching,  as  opposed  to  conventional  day-by- 
day  switching,  of  the  various  versions.  This  technique  of  on-line 
switching  has  been  used  successfully  to  test  a  paging  replacement 
algorithm,  various  time-slicing  constants  and  the  effect  of 
assigned  priorities  on  the  user  in  a  time  sharing  system. 


CAMPBELL6P  CP16,874 

Campbell,  D.J.,  and  Heffner,  W.J.;  Measurement  and  Analysis  of 
Large  Operating  Systems  During  System  Development;  Proceedings  of 
the  FJCC,  vol.33,  part  1  (1968)  pp. 903-914. 

While  this  paper  touches  upon  simulation  and  other  methods  to  pre¬ 
evaluate  system  performance,  the  primary  thrust  is  on  the 
incorporation  of  on-line  measurement  tools  into  the  evolving 
system  so  that  performance  may  be  monitored  and  improved  once 
operation  begins.  The  strat^^gic  placement  of  measurement  hooks 
requires  that  the  critical  parameters  of  the  final  system  be 
identified  in  advance,  a  task  which  can  lead  to  better 
implementation  in  the  first  place. 


CANTRELL68 

Cantrell,  H.N.,  and  Ellison,  A.L.;  Multiprogramming  System 
Performance  Measurement  and  Analysis;  Proceedings  of  the  SJCC, 
vol.  32  (1968)  pp. 213-222. 


CUUMING^I  CP23,20S 

Cumming,  C.B,;  Monitoring  the  Operation  of  System  Software; 
Software  --  Practice  and  Experience,  vol.  1,  no,  4  (1971) 

pp.  .^93-339  , 


DENISTON69  CR18,273 

Deniston,  W.R,;  SPIF:  A  TSS/360  Software  Measurement  Technique; 
Proceedings  of  the  ACM  24th  National  Conferenc<=»  (  1969)  pp.  229-245, 


DEUTSCH72 

Deutsch,  P, ,  and  Grant,  C,A, ;  A  Flexible  Measurement  Tool  for 
Software  Systems;  Proceedings  of  TFIP  Congress  71,  vol,  1  (1972) 
pp, 320-326, 


FOX67  CP14,067 

Fox,  D, ,  and  Kessler,  J,L,;  Fxperiments  in  Software  Modeling; 
Procef^dings  of  the  FJCC,  vol,  3  1  (1967)  pp, 429-436, 


GOTLIFB70  7*9 

Gotlieb,  C.C,,  and  MacFwan,  G,H,;  System  Evaluation  Tools;  in 
Buxton,  J,N.,  and  Pandell,  B,  (<^d,).  Software  Enqineorirg 
Techniques  (1970)  pp, 93-99. 


GPAHAM71  q’^'iq 

Graham,  P,M,,  Clancy,  G,J,,  and  PeVaney,  D,P,;  A  Software  Design 
and  Evaluation  System;  Proceedings  of  the  ACM/SIGOPS  Workshop  on 
System  Performance  Evaluation  (April  1971)  pp, 200-213, 

There  are  two  primary  drawbacks  to  modelling  as  a  part  of  the 
implementation  process.  First  is  the  need  to  construct  the  model 
separately  from  the  system,  diverting  people  from  the  primary 
objective.  Second  is  the  problem  of  keeping  the  model  current  as 
the  system  primitives  are  re-defined, 

DES  makes  use  of  a  single  language  to  describe  the  object  system 
at  all  levels  of  design  and  implementation.  In  this  way 
simulation  goes  hand-in-hand  with  design  and  the  performance  of 
the  final  system  may  be  accurately  estimated  before  full 
implementation,  poten-'-ially  saving  a  costly  re-design. 


GPAHAM73b  CF25,424  3*11 

Graham,  P,M.,  Clancy  Jr,,  G,J,,  and  Devaney,  D,E,;  A  Software 
Design  and  Evaluation  System;  Communications  of  A.CM,  vol,  16,  no,  2 
(Feb,  1973)  pp,  1  10-1  1  6, 
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The  DES  system  is  an  operating  s 
in  a  superset  of  PL/1.  Proced 
characteristics  are  maintained 
simulating  the  performance  of  i 
Each  component  can  be  evaluated 
of  the  procedure,  information  on 
usage  and  interface  and  constr 
produces  a  probabilistically  co 
system  which  is  input  to 
Unfortunately,  asynchronous  behav 
Essentially,  this  is  still  a  *  to 
that  no  large  sys-^-em  like  the  Mul 
modelled . 


ystem  writing  system,  implemented 
ures,  data  items  and  hardware 
in  a  data  set  that  aids  in 
ncompletely  written  subsystems, 
to  produce  a  graph  representation 
external  references,  resource 
aint  violations.  The  methodology 
llapsed  graph  of  the  original 
a  general  purpose  simulator, 
ior  is  not  adequately  modelled, 
y’  system  since  its  authors  admit 
tics  system  could  be  successfully 


HATFIELD71  CR23,271 

Hatfield,  D.,  and  Gerald,  J.;  Program  Restructuring  for  Virtual 
Memory;  lEM  Systems  Journal,  vol.  10,  no.  3  (1971)  pp. 168-192. 

Much  effort  has  been  directed  of  late  to  the  improvement  of 
problem- program  performance  on  virtual  memory  systems.  This  paper 
describes  a  procedure  for  determining  the  memory-use 
characteristics  of  a  program  and  then,  through  a  combination  of 
automatic  and  manual  algorithms  and  heuristics,  rearranging  th 
code  to  improve  paging  behavior.  The  method  described,  as  oppose 
to  many,  is  practical,  in-use,  and  results  in  a  (typically)  5  to  1 
improvement. 

KIMBLETON72  CR23,879 

Kirableton,  S.R.;  P<=rformance  Evaluation  -  h  Structured  Approach; 
Proceedings  of  the  SJCC,  vol. 40  (1972)  pp. 411-416. 

This  paper  is  concerned  with  evaluating  the  performance  of  a 
computer  system,  including  its  operating  system .  Although  directed 
towards  evaluation  for  purposes  of  selection  and  comparison,  the 
ideas  presented  are  relevant  with  regard  to  the  improvement  or 
evaluation  of  a  particular  programming  or  operating  system  for  a 
particular  machine.  In  particular,  the  point  is  made  that  usually 
a  few  key  variables  drive  the  entire  system. 


KULSRUD74 

Kulsrud,  K. E. ;  Some  Statistics 
Software  Practice  and  Experience, 
pp. 241-249. 

This  paper  describes  a  distributi 
on  a  statistical  survey,  the  auth 
program  writing,  program  corre 
languages  used  in  the  survey  are 
conclusions  are  given  but  it  may 
the  area  of  "better  programming  1 
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on  Reasons  for  Compiler  Use; 
Vol. 4,  No. 3,  (July-Sept.  1974), 

on  of  Compiler-time  usage.  Eased 
or  reports  user's  time  used  in 
ction,  program  checking  etc.  The 
FORTRA.N  and  IMP.  No  concrete 
lead  to  further  investigations  in 
anguages . " 
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LASSETTPE72 


CP24, S94 


Lassettre,  F.P.,  and  Scherr,  A,L.;  Modelling  the  Perfo 
the  OS/360  Time-Sharing  Option  (TSO) ;  in  Freiberger,  W 
S t at istica 1  Cgm£uter  Performance  Evaluation,  Academic  Pre 
pp,  57-72. 

When  properly  handled,  modelling  can  be  an  invaluable  to 
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LUCAS 71 

Lucas ,  H . C. ; 
Surveys,  vol. 

Performance  E 
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LDCAS73 


Lucas,  H.C.,  and  Presser,  L. ;  A  Method  cf  Software  Evalua 
Case  of  Language  Translators;  The  Computer  Journal,  vol, 
{Aug.  1973)  pp.  226-231  . 
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MAPGOLIN72 

Margolin,  B.H.,  Parmelee,  R.P.,  and  Schatzoff,  M. ;  An 
Free  Storage  Algorithms;  in  Freiberger,  W.  (ed.),  St 
Computer  Performance  Evaluation,  Academic  Press  (1972). 
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A  description  of  an  excellent  melding  of  system  measurement, 
statistical  techniques,  modelling  and  experiment  design  which 
resulted  in  a  subs-*- ant  ial  improvement  in  the  CP-67  operating 
system.  Highly  recommended  to  those  interested  in  banging  existing 
software  into  shape. 


MILLFP72 

Hiller,  F.F,;  Pibliograpy  on  Techniques  of  Computer  Perfomance 
Analysis;  Computer,  vol.5,  no. 5  (September/  October  1972)  pp,39- 

47. 

Though  many  of'  the  'entries  in  this  bibliography  are  system- 
oriented,  there  are  still  more  which  can  provide  ideas  for 
structuring  programs  in  an  attempt  to  improve  their  operating 
efficiency. 


NEMETH71  CR22,645  1*10 

Nemeth,  A.G.,  and  Povner,  P.D.;  riser  Program  Heasurement  in  a 
Time-Shared  Environment;  Communications  of  the  ACH,  vol.14,  no. 10 
(Oct.  1971)  pp. 661-666. 

The  article  presents  a  method  used  on  the  TX-2  computer  at  the  MIT 
Lincoln  Laboratory  for  the  measurement  of  time  usage  distribution, 
number  of  supervisor  program  requests,  siz'^  of  request  bloc)cs  and 
frequency  counts  of  user-specified  events.  It  is  a  combined 
software  and  hardware  system  that  allows  interactive  measurement 
of  program  performance  under  user  control.  The  events  to  be 
measured,  the  frequency  of  sampling  these  events,  the  distribution 
controlling  any  random  variation  in  sampling  frequency,  the 
segment  of  the  program  to  be  measured  and  the  format  of  the  output 
are  all  user-controlled  in  this  system,  which  has  been  used  to 
debug  large  programs  fcund  to  have  time  inefficiencies  not 
susceptible  to  logical  identification. 


PAHNAS67  CP14,055  3*10 

Parnas,  D.L.,  and  Darringer,  J.A.;  SOPAiS  and  a  Methodology  for 
System  Design;  Proceedings  of  the  FJCC,  vol.31(1967)  pp. 449-474. 

SODAiS  is  the  first  of  a  number  of  systems  which  attempt  to  combine 
simulation  with  design  and  implementation  in  an  effort  to  increase 
system  production  <=fficiency.  SODA\5  allows  the  modules  of  the 
"object  system"  to  be  specified  at  any  desired  level  of  detail  and 
in  a  numb<^r  cf  different  languages,  and  provides  several 
advantages:  all  interfaces  are  completely  specified;  the 
"fracturing"  of  the  system  into  its  various  modules  is  shewn  to  be 
correct  or  incorr'^ct  prior  to  implementation;  it  is  possible  to 
determine  at  the  outset  if  low-level  inefficiencies  imposed  by 
high-level  design  decisions  will  significantly  impact  the 
performance  of  -t-he  resulting  system.  Parnas’s  system  has  several 
drawbacks  (compared  to,  say,  P.M.  Graham’s  D.E.S.);  primarily  the 
use  of  several  different  languages  is  confusing,  particularly 


-10  3- 


since  the  implementation  language  is  dis-t-inct  from  the  simulation 
language  (s) . 


PINKEPTONfiQ 

Pinkerton,  T.B.;  Performance  f^onitoring  and  Systems  Evaluation;  in 
Naur,  P. ,  and  Pandell,  B.  (ed).  Software  Engineering  (1969) 
pp, 200-203 . 


SEAf1^N69  CP  IB,  98  5 

Seaman,  P.H.,  and  Soucy,  P.C.;  Siraula-t-ing  Operating  Syst^^ms;  TPfl 
Systems  Journal,  vol.8,  no.U  (1969)  op, 264-279. 


WFIDERMAN7 1 

Weiderman,  N.H.;  Synchronization  and  Simulation  in  Operating 
System  Construction;  Ph.D.  Thesis,  Cornell  University,  Department 
of  Computer  Science  (September  1971). 

Description  of  an  operating  system  design  methodology  which 
proceeds  in  a  strict  top-down  order  and  combines  simulation  wi-^h 
implementation  to  verify  system  structure  and  predict  object- 
system  performance.  A  good  review  of  other  technigues  is 
included;  chapters  three  and  four  are  of  particular  interest.  For 
comparison  purposes,  see  Graham’s  D.E.S.,  Parnas’s  SODAS  and  the 
Zurcher  and  Fandell  paper. 


ZURCHFP6B  CR17,922  2*15 

Zurcher,  F.W.,  and  Pandell,  B. ;  Iterative  Multilevel  Modeling  -  A 
Methodology  for  Computer  System  Design;  Proceedings  of  IFIP 
Congress  1968  (1^68)  pp.  1  38-  142. 

The  authors  describe  a  philosophical  and  practical  approach  to  the 
design  of  complex  software  systems.  In  contrast  to  Dijkstra’s 
structured  programming,  the  method  proceeds  in  a  strictly  top-down 
manner;  as  opposed  to  Weiderman’s  "implementation  cum  model," 
Zurcher  and  Pandell  propose  basically  a  system  model  which 
produces  a  working  implementation  as  a  (very)  useful  side-effect. 


TOPICS 
Evaluation ; 

Alexander71,  Arbuckle66,  Arvey73,  Cantrell68,  Cheat ha m72b, 
Cohen74,  Cumming71,  Gotlieb70,  Kay69,  Kimbletcn72,  Lucas73, 
Miller72,  PandellTI,  Wortman72; 

M  odel 1 ing : 

Bal2er69,  Bard72,  Fox67,  Lassettre72,  Margclin72; 
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Simulation : 

Carapbell6B,  Graham71,  Grahaiu73b,  Parnas67, 
Seamar.60,  Siipnik71,  Weiderman71,  Zurcher68; 

Monitoring : 

Arf3en69,  Bard71,  Bard73,  Campbell68,  Cumming71 
Denistone69,  Deutsch72,  Hatfield71,  Lucas71, 
Pinkerton6  9 . 


Parna  s69b , 


Dak in73  , 
Neme  t h7  1 , 


XII*  documentation 


AUEPBACH72  2*15 

Auerbach;  Documentation  Aids;  Auerbach  Standard  EDP  Reports; 

Auerbach  Info,  Inc,,  no. 8  (1972). 

This  is  an  extensive  and  essentially  complete  survey  of 
documentation.  Various  uses  of  documentation  during  project 

planning,  implementation  and  maintenance  are  described.  The 

elements  of  documentation  (e.g,,  history  and  status,  glossaries, 
program  description,  equipment  and  software  environment)  are 
enumerated  and  justified.  Since  Auerbach  is  essentialy  a  software 
products  handbook,  the  main  focus  of  the  paper  is  on  what 

automatic  documentation  can  and  should  do  for  a  program.  The 
capabilities  of  text  and  comment  processing,  intention  abstraction 
and  graphical  flowcharting  or  paragraphing  are  investigated  in 
relation  to  the  components  of  a  program.  The  component 
descriptions  discussed  are  functional  relations,  data  bases,  files 
and  tables. 


CONROW70 


5*10 


Conrow,  K,,  and  Smith,  P.G.; 
Reformatter;  Communications  of 
pp, 669-675. 


NEATER2:  A  PL/I  Source  Statement 
the  ACM,  vol.13,  no. 1 1  (1970) 


The  paper  describes  a  PL/I  program  wh 
programs  to  show  their  logical  structure, 
helps  debugging  in  that  it  makes  it  eas 
see  where  the  program  does  not  confor 
intended.  In  addition  simple  syntacti 
program  (e.g,,  missing  string  quotes).  T 
discouraged  as  this  confuses  the  log 
which  inserts  statements  to  collect  us 
available. 
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GOOS73 

Goos,  G. ;  Documentation;  in  Bauer,  F. L.  (ed.).  Advanced  Course  on 
Software  Engineering,  Springer  Verlag,  New  York  (1973)  pp. 385-394. 

MEADOW66  CP13,305 

Meadow,  C.T.,  and  Waugh,  D.V.;  Computer  Assisted  Interrogation; 
Proceedings  of  the  FJCC,  vol.  29  (1966)  pp. 381-394. 

MENKnS70  CR20,783  1*10 

Menkus,  P.;  Defining  Adequate  Systems  Documentation;  Journal  of 

Systems  Management,  vol.  21,  no.  12  (December  1970)  pp, 16-21. 
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and  the  proliferation  of  forms  and  paperwork.  The  types  and 
functions  of  documentation  are  discussed  and  effective  methods  are 
presented  with  an  11-point  checklist. 
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ntation  for  PL360;  Communications 
970)  pp. 216-222. 

ct ive  system  that  parses  a  PL360 
nteractively  interrogates  the 
of  each  main  syntactic  construct, 
y  source  line  is  well  documented, 
re  kept  in  an  online  program 
an  subsequently  be  asked  about 
se  of  certain  classes  of  actions. 

documentation  given  a  keyword 
em  is  essentially  experimental, 
future  automated  documentation 


PEARSON73 


2*7 


Pearson^  Cataloguing  Computer  Software; 

no. 10  (October  1973)  pp. 87-91. 


Datamation,  vol.19. 


This  article  discusses  t 
software,  and  argues  that 
espouses  his  own  syste 
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the  programmer  should 
programming  style  of  an  i 
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SC0WEN71  3*6 

Scowen,,  R.S.,  Allin^,  D.  ^  Hillman,  A.D.,  and  Shimell,  M.  ;  SOAP  -  A 
Program  which  Documents  and  Edits  ALGOL60  Programs;  Computer 
Journal,  vol. 14,  no. 2  (1971)  pp. 133-135. 

This  paper  discusses  SOAP,  a  paragrapher  for  ALGOL60  programs. 
The  program  is  a  sort  of  parser,  doing  some  syntax  checking.  The 
program  allows  the  option  of  replacing  any  token  terminal  wherever 
it  occurs  with  another  terminal.  The  documentation  referred  to, 
however,  is  only  a  cross-reference  listing,  with  some  nice 
features.  The  paragrapher,  then,  does  not  really  do  any 
documentation,  but  merely  produces  bookkeeping  listings. 
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SELir,6  9 


1*1  1 


Selig,  F, ;  Documentation  Standards;  in  Naur,  P.,  and  Randell,  B. 
(ed.).  Software  Engineering  (1969)  pp. 209-211. 


VAN  DUYN72 


2*B 


Van  Duyn,  J, ;  Documentation  Manual;  Auerbach,  Philadelphia  (1972) 

p  p ,  1  -  1  5  8 . 


This  is  a  compact  paperbaclc  which  covers  documentation  of 
processing  systems.  The  book  is  organized  as  a  set  of  temp 
for  each  part  of  the  documentation  with  one  or  two  case  studi 
illustrate  each  section.  The  approach  is  rigid  and  is  prof 
illustrated  with  forms,  charts,  and  tables.  The  author  doe 
feel  it  necessary  to  justify  the  methods  presented,  since  the 
taken  from  practices  that  are  standard  and  widely  accepte 
least  in  the  commercial  programming  field. 
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NALSH69 


CR1 9, 392 


2^9 


Walsh,  Do  ;  A  ljuide  to  Software  Documentation ;  McGraw  Hill,  N.Y, 
(1969)  pp. 1-157. 


This  paper  is  a  d 
documentation  for  any 
through  the  product 
no  examples  are  in 
usefulness.  Moreove 
of  documentation,  nor 
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software  engineering. 
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WATKINS73 


Watkins,  B.P,;  Towards  a  Theory  of  Documentation;  The  Australian 
Computer  Journal,  vol.5,  no. 2  (May  1973)  pp. 57-61. 


An  advance  is  made  toward  the  theory  of  documentation  b 
definition  of  intensional  documentation,  extens 
documentation,  and  level  of  detail.  This  provides  a  f 
statement  of  the  structure  of  documentation.  The  statement 
only  matches  the  current  intuitive  concepts,  but  gives  a  d 
insight  into  the  reasons  for  and  values  of  these  structures. 
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TOPICS 

Other  documentation  papers: 

Belady71,  BemerbP,  Brinch  Hansen73a,  Brown74,  Brophy70, 
Rrooks75,  Fosdick72,  Garwick61,  Haberman73,  Int . Com pu te rs70 , 
Kay69,  Kerpelraan71,  Maynard72,  Mills73b,  Parnas72e,  Poole73 
Simmons72 . 
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XIII*  Miscellaneous 


Highly  recommended:  Cheatham72b 


ARDEN72  CR25,2B6 

Arden,  RoWo,  Flanigan,  L.K,,  and  Caller,  B.A.;  An  Advanced  System 
Programming  Course;  Proceedings  of  IFIP  Congress  71,  vol.  2  (1972) 
pp.  1510-1*^14. 


CHEATHAM72b 


CR23, 734 


2*13 


Cheatham,  T.E.,  and  Wegbreit,  B. ;  A  Laboratory 
Automating  Programming;  Proceedings  of  the  SJCC, 

pp, 11-21, 


for  the  Study  of 
Vol. 40,  (1972) , 


This  paper  deals  with  facilit 
automating  programming.  The  t 
defining  programming  as  a  pro 
procedure  capable  of  performing  a 
object,  given  a  precise  specif i 
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DARDEN70  CR20,838 

Darden,  S,  and  Heller,  S. ;  Streamline  Your  Software  Development; 
Computer  Decisions,  vol. 2,  no. 10  (Oct.  1970)  pp. 29-33, 


DONOVAN'^0 

Donovan,  J.J.;  Software  Engineering  -  An  Experiment  and  a  Report; 
IFIP  World  Conference  on  Computer  Fducat ion  ( 1 970)  . 


HOLT72  2*15 

Holt,  R.C,,  Teaching  the  Fatal  Disease  (or)  Introductory  Computer 
Programming  Hsing  PL/I;  Dept.  of  Computer  Science,  University  of 
Toronto,  Report  RCH-1,  (December  1972),  pp.16. 


The  author  presents  a  num 
to  teach  computer  progr 
compares  PL/I  to  FORTRAN 
but  recognizes  that  it  is 
rigid  restrictions  as 
PL/I  in  an  endeavour  to  s 
claims  to  have  suceede 
concerned , 


MAUREP70 

Maurer,  W,;  Generalized 
J.T.  (ed.).  Software  Engineering,  vol.1,  Academic  Press,  N, Y. 
(1970)  pp.  139-150.'"” 


NEEDHAMTOb  7>*'12 

Needham,  R.M.,  and  Aron,  J.D.;  Software  Engineering  and  Computer 
Science;  in  Buxton,  J. N« ,  and  Randell,  B,  (ed.).  Software 
Engineering  Technigues  (April  1970)  pp.113-11U. 

Computer  science  aims  at  defining  general  principles  underlying 
the  design  and  application  of  software  systems.  The  software 
engineer  wants  to  malce  something  which  works;  where  working 
includes  satisfying  commitments  of  function,  cost,  delivery  and 
robustness.  ’'Pending  major  theoretic  advances,  software 
engineering  should  concentrate  on  the  development  of,  and  the 
exchange  of  experience  about,  practical  tools  such  as;  diagnostic 
aids,  protected  testing  facilities,  automatic  or  semi-automatic 
fallback,  aids  to  continuity  during  development,  etc.” 


ber  of  pitfalls  which  exist  in  attempting 
amming  via  the  vehicle  of  PL/I.  He 
and  COBOL,  ccmes  out  liking  PL/I  better, 
far  from  ideal.  He  presents  some  guite 
guidelines  for  teaching  programming  using 
timulate  controversy  and  discussion.  He 
d  as  far  as  the  controversy  aspect  is 


CF2  1 , 548 

Interpretation  and  Compilation;  in  Tou, 


PARNAS72a 

Parnas,  P.L. ;  A  Course  on  Software  Engineering  Technigues;  SIGCSE 
Bulletin,  vol.  4,  no.  1  (March  1972)  pp. 154-159, 


PERLIS69 

Perlis,  A.J.;  Identifying  and  Developing  Cirricula  in  Software 
Engineering;  Proceedirgs  of  the  SJCC,  vol.  34  (1969)  pp. 540-541. 


SHAW72  CP25,285 

Shaw,  A.W.  and  Weiderman,  N. H. ;  A  Multiprogramming  System  for 
Education  and  Research;  Proceedings  of  IFIP  Congress  71,  vol.  2 
(1972)  pp. 1505-1509. 


STONE72  1^15 

Stone,  M.;  In  Search  of  An  Identity;  Datamation,  vol, 18,  no. 3, 
(March  1972),  pp. 52-59. 
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The  author  attacks  the  problem  of 
programmers  in  society.  A  broad  range 
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A  NETWORK  ’^’^AMFWORK  FOR  RELATIONAL  IMPLEMENTATION 
D.  Tsichritzis,  February  1975 

A  UNIFIED  APPROACH  TO  FUNCTIONAL  DEPENDENCIES 
AND  RELATIONS 

P.A.  Bernstein,  J.P.  Swenson  and  D.C.  Tsichritzis 
February  197f 

ZETA:  A  PROTO'^YPE  RELATIONAL  DATA  BASE 

MANAGEMENT  SYSTEM 

M.  Brodie  (ed) .  February  1975 

AUTOMATIC  GENERATION  OF  S Y NTAX- REP AI R IN G  AND 
PARAGRAPHING  PARSERS 
David  .  Barnard,  March  1975 
[M.Sc.  '^hesis,  DCS,  1975  ] 

QUE^Y  EXECUTION  AND  INDEX  SELECTION  FOR  RELATIONAL 
DATA  BASES 

J.H.  Gilles  Farley  and  Stewart  A.  Schuster,  March  1975 
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